Build iOS app without a Mac: what actually changed

For most of the App Store's existence, shipping to iOS required owning a Mac. That was a capital purchase before a single user existed, and for teams in India and across much of the mid-market it was a real reason iOS shipped late or not at all. You can now build iOS app without a Mac workflows using Expo Application Services, which turns a hardware purchase into an operating cost.

The barrier that remains is the Apple Developer account, and it is worth being precise about which constraints actually disappeared.

What EAS does

EAS Build packages native binaries for both platforms from your terminal, whatever your local operating system. The build runs on Expo's infrastructure, so the Xcode toolchain requirement moves off your desk.

The documented workflow removes most friction at credential handling, because signing is where iOS releases usually stall. If you have no distribution certificate or provisioning profile, EAS prompts you to log in to your Apple Developer account, then generates the certificates and stores them in Expo's cloud vault. For Android it can generate and manage the keystore too.

Anyone who has managed iOS signing by hand will recognise what that replaces: certificates on one person's laptop, a provisioning profile that expired during a release, and the recurring question of who still has the keystore. Centralising it is worth as much as removing the hardware.

It is worth separating two things that often get conflated. Running the build elsewhere is the easy half and several services have offered it for years. Having the build service also hold and rotate your signing material is the half that removes the recurring pain, because certificate expiry is the failure that reliably catches teams at the worst moment — typically when the person who created it has left and nobody knows which Apple ID it belongs to.

What it does not remove

Three things survive, and pretending otherwise causes bad planning.

The Apple Developer account. Still required for production iOS builds. Simulator builds can be tested without an active paid account, which is genuinely useful for evaluating whether a project is viable before committing, but anything reaching a real device or the store needs the membership.

App Store review. Nothing about cloud builds changes the queue or the guidelines.

Real-device testing. A cloud build produces a binary, not confidence. You still need physical iPhones in the hands of people who will use the app, and the range of devices matters more than the build environment ever did.

There is also a build economy to plan around. The free tier gives 30 build credits per month across Android and iOS combined; paid tiers buy priority in the queue. Thirty is comfortable for a small team on a normal cadence and disappears quickly during a release week when every fix triggers a rebuild.

Which makes the next distinction the important one commercially.

Plan the credit budget against release weeks rather than an average month. A team shipping steadily might use six or eight a month and then burn fifteen in three days stabilising a launch, which is exactly when a queue delay is least welcome. Knowing the ceiling before that week is cheaper than discovering it during.

Most changes do not need a build at all

Binary builds are mandatory only when native dependencies or permissions change. JavaScript and TypeScript changes go out over the air, bypassing store review entirely.

That is the detail that reframes the whole economics. A team shipping weekly copy changes, layout fixes, business-logic corrections and bug fixes in application code is not consuming build credits and is not waiting for review. Builds become the exception — a new native module, a permission, an SDK upgrade — rather than the release process.

It is also the reason over-the-air updates have become load-bearing for React Native teams generally, which is why the retirement of the previous default mattered so much and why we wrote about where React Native OTA updates went after CodePush was archived. If you are choosing tooling now, the build story and the update story should be decided together, because in practice you will use the second far more often than the first.

Who the build iOS app without a Mac shift actually helps

Not everyone. For an established team with Macs, CI and a working signing setup, this is a convenience rather than a shift.

It matters for three situations we see regularly.

Validating iOS before committing to it. A company with an Android product deciding whether iOS is worth it can now find out without buying hardware first. That reorders the decision sensibly: prove the demand, then spend.

Distributed and contract teams. A developer without a company-issued Mac can produce a signed build. The alternatives were shipping hardware, a remote Mac service, or the one person with a Mac becoming the release bottleneck — which is a single point of failure everyone tolerates until they are on holiday.

Cost-constrained builds. In the Indian market specifically, a Mac per mobile developer is a meaningful line in a project budget, and it arrives before any revenue does. Converting it to a subscription that scales with activity changes which projects are viable at all, which is the part that matters more than the tooling.

One organisational note that matters more than the tooling. Once builds and signing are centralised, the release process stops being tied to an individual and becomes a documented pipeline anyone on the team can run. That is a resilience gain worth as much as the cost saving, and it is invisible until the week your mobile lead is unavailable and something needs to ship.

There is a caveat on over-the-air updates worth carrying, because it is where teams get careless. Store policy permits shipping fixes and content this way; it does not permit materially changing what the app does after review. The line is rarely tested in practice and the sensible posture is to treat OTA as a mechanism for fixes and refinements rather than for features you would have expected a reviewer to look at.

Two adjacent capabilities are worth knowing about while you are here, because they change how the rest of the team works. Internal distribution builds let testers and stakeholders install a real binary from a link rather than waiting on TestFlight processing, which shortens the feedback loop on design and content decisions considerably. And because builds are reproducible on someone else's infrastructure rather than a specific laptop, a build from three months ago can be reproduced when a regression needs bisecting — which is harder than it sounds when the toolchain lives on a machine that has since been upgraded twice and nobody recorded which Xcode version produced the release.

The honest trade-offs

Two, and both are about dependency rather than capability.

Your signing certificates live in a vendor's vault. That is better than a laptop for most teams — it is backed up, it survives an employee leaving, and it is auditable. It is also a third party holding the keys to your app's identity, which is a supplier-risk conversation your security review should have rather than discover. The mitigation is to understand the export path before you need it.

And build infrastructure becomes someone else's uptime. A queue you cannot influence is fine on an ordinary Tuesday and uncomfortable during an incident when a hotfix needs a native build. Worth knowing whether your release path has a fallback, even a slow one.

Neither is a reason to avoid it. Both are reasons to have thought about it before a release depends on it, and both are ordinary supplier questions rather than anything specific to mobile.

The wider point is that the fixed costs of mobile development have been falling steadily and the decision points have moved. It is no longer hardware, or signing, or even the build pipeline. It is the same question it has always been for the products we help teams ship — whether the app is worth building, and whether you can maintain two platforms' worth of quality once it exists. That second question is where the cross-platform framework choice earns its keep, and it is the conversation we would rather have with a client than one about laptops. If you are weighing an iOS launch, that is squarely React Native and mobile territory and the hardware question no longer needs to be part of it.