Build and Sign iOS Apps Without a Mac

ios-builder is a Go command-line tool that lets you build, sign and hot-reload iOS apps from Windows or Linux. It generates a GitHub Actions workflow targeting macOS runners, dispatches the build, waits, and drops the finished IPA into your dist/ folder.

Of everything in this series, this is the one most likely to change how a Windows-based team works on Monday morning.

Key takeaways

• The build still runs on macOS — you just do not own the Mac. It is a GitHub Actions runner, billed by the minute.
• Code signing genuinely does not need a Mac. The certificate request and the .p12 are cryptography, and the tool does both locally.
• Six frameworks detected automatically from the folder layout — Swift, React Native, ejected Expo, Flutter, Kotlin Multiplatform, Cordova/Ionic.
• Hot reload for Flutter and React Native against a real device. Kotlin Multiplatform cannot, and the reason is architectural.
• The economics are the real constraint: about 15–20 free builds a month, because macOS minutes bill at ten times.
• Apple's requirements are untouched. You still need a paid developer account.

Why is this such a persistent problem?

Because Xcode only runs on macOS, and Xcode is the only thing that can compile and sign an iOS app. Every cross-platform team eventually collides with that.

Picture a typical agency setup. Six developers on Windows, building a React Native app for a client. Five of them can do every piece of the work — components, state, API integration, Android builds, tests — and then the iOS build lands on the one person with a MacBook. That person becomes a queue. Every demo, every TestFlight upload, every "can you check this on an iPhone" goes through them, and their holiday becomes a project risk.

The usual fixes are all purchases. Buy Macs for everyone. Rent a Mac mini. Pay for a hosted CI service. Each is defensible, and each turns a workflow annoyance into a line item.

Then there is signing, which has its own folklore. Almost everyone believes you need Keychain Access on a Mac to produce a certificate signing request and a .p12. That belief is wrong, and it is the most useful thing in this post.

How does ios-builder work?

1. Detect the project. builder init inspects the directory structure and works out which framework it is looking at, then generates the Actions workflow for it.
2. Dispatch the build. builder ios build triggers that workflow on a macOS runner, polls it, and downloads the IPA to ./dist/. From your side it is one command that takes a few minutes.
3. Handle signing locally. builder signing csr generates a private key and certificate signing request on your machine. You upload the CSR to Apple, download the issued certificate, and builder signing p12 assembles the bundle. builder signing setup pushes both into GitHub secrets so the runner can sign with them.
4. Iterate on a device. builder dev flutter watches your Dart files and triggers hot reload on a connected device; builder dev rn does the same for React Native and starts Metro if it is not running.

The framework detection table is worth internalising, because it is entirely convention-based:

Getting to a first build

Install via Homebrew, the install script, or by downloading builder.exe from the releases page on Windows. Then three commands:

builder auth github          # GitHub authentication
builder init                 # Workflow setup
builder ios build            # Trigger build and download IPA

If you want to check the pipeline before dealing with Apple at all, builder ios build --unsigned skips signing entirely. That is the right first step: prove the build works, then fight the certificates.

The economics, stated plainly

This is where the plan meets reality. GitHub's free tier gives 2,000 Actions minutes a month, but macOS runners bill at a ten times multiplier. That leaves roughly 200 effective macOS minutes — about fifteen to twenty iOS builds.

Fifteen builds a month is comfortable for a project in maintenance. It is nothing during an active sprint where you build several times a day. So the honest positioning is: this tool removes the hardware requirement and replaces it with a metered one.

That is still usually a better deal. Actions minutes are a variable cost you can turn off; a Mac mini is capital, and a MacBook for every developer is a serious number. But go in with build discipline — build on merge, not on every push — rather than assuming free means unlimited.

Alternatives worth knowing

• Expo EAS Build — if you are on Expo, this is the path of least resistance and it is very good. Paid, hosted, managed. You give up transparency and gain a lot of time.
• Codemagic or Bitrise — mature mobile CI with proper dashboards, test device farms and store submission built in. More expensive, considerably more capable.
• Hand-written GitHub Actions — exactly what ios-builder generates, without the tool. If you already have a DevOps person and want no extra dependency, write the workflow once and keep it.
• One shared Mac mini — unfashionable but effective. A single machine as a build server, accessed remotely, is often cheaper than a year of hosted CI and gives you a real Xcode when something goes wrong.

Limitations to plan around

• The macOS minute multiplier is the hard ceiling. Plan your build cadence around it.
• Kotlin Multiplatform has no hot reload, and it may need an explicit JDK version set in the config file before it builds at all.
• Device features need the MobAI app, and simulator sharing needs a paid subscription. The open-source CLI and the commercial product are intertwined.
• React Native hot reload needs the same WiFi as the Metro host. Fine in an office, awkward for remote teams.
• No Xcode means no Xcode debugging. When a build fails for an Xcode-specific reason, you are reading CI logs instead of using Instruments. Keep one Mac somewhere for the bad days.

Conclusion

ios-builder does not defeat Apple's platform requirements. It relocates them — from hardware you buy to minutes you rent, and from a person's desk to a pipeline anyone can trigger.

For a Windows-based team shipping React Native or Flutter, that is the difference between one bottleneck and none. And the signing insight is worth the read on its own: the certificate dance never needed a Mac. It just needed someone to say so.

Shipping mobile apps from a Windows team?

DI Solutions builds React Native and Flutter apps and sets up the pipelines that get them onto real devices and into the stores, without a Mac on every desk. Talk to our mobile team about your build setup.

Reference links

• ios-builder on GitHub
• GitHub Actions billing — including the macOS multiplier
• Apple Developer — certificates