Building and signing an iOS app on Windows

The short answer is that you can write an iOS app on Windows, but you cannot compile or sign one there. Xcode runs on macOS only, and the toolchain that turns source code into a signed .ipa lives inside it. Every workable approach on Windows comes down to the same thing: getting access to a Mac somewhere, whether that is a machine you rent by the hour, a CI runner, or a cloud build service.

This guide draws the line precisely, because a lot of the advice online is either too pessimistic ("you need a Mac, end of story") or too optimistic ("just use a VM"). Knowing exactly which steps need macOS tells you how much Mac time you actually have to pay for, which is usually far less than people expect.

What works fine on Windows

More than you might think. All of the following are fully supported from a Windows PC:

What genuinely requires macOS

Three things, and they are all downstream of the same constraint: Apple ships these tools as macOS binaries and does not license them for other platforms.

Compiling

The iOS SDK, the Swift compiler as Apple ships it, and xcodebuild are macOS-only. There is no supported way to produce an iOS binary on Windows.

Signing

The codesign tool is a macOS binary that talks to the system Security framework. Third-party reimplementations exist but are not supported by Apple and are a poor idea for App Store builds.

Notarization and upload

notarytool and the Transporter workflow that submit builds to Apple ship inside Xcode's command line tools. See notarytool.

Four ways to get a signed build without owning a Mac

1. A macOS CI runner

The most common answer, and usually the cheapest. GitHub Actions, GitLab, CircleCI, and Bitrise all offer hosted macOS runners billed by the minute. You push from Windows, the runner compiles and signs, and you download the artifact or ship it straight to TestFlight. You never touch a Mac interactively.

The catch is that a fresh runner has an empty keychain, so every build has to import signing material from somewhere. That problem, and the ways to solve it, is covered in depth in Apple code signing in CI/CD.

2. A rented cloud Mac

MacStadium, AWS EC2 Mac instances, and Scaleway rent real Apple hardware by the hour or month. You get a full desktop over VNC or SSH. This is the right choice when you need Xcode interactively: debugging on a simulator, profiling with Instruments, or working through an App Store rejection. It is more expensive than CI minutes, so most teams use it occasionally rather than continuously.

3. A managed mobile build service

Codemagic, Xcode Cloud, and Bitrise wrap the runner in a product with iOS-specific defaults. Less to configure than raw CI, less control, and signing is typically handled by handing the service your credentials. Reasonable if you want to avoid thinking about macOS at all.

4. Borrow a Mac for setup only

Worth knowing because it is often enough. If you can get an hour on a friend's Mac or at an Apple Store, you can create your certificates and export them as .p12 files, then never need that Mac again. From then on the private key travels with you and any runner can use it.

Managing signing material from Windows

Whichever route you pick, the recurring problem is the same: certificates expire, provisioning profiles need regenerating when you add a device, and the machine doing the signing needs the right material at the right moment. None of that administration requires macOS, even though the signing itself does.

The HexSign CLI ships a native Windows binary and stores its credentials in Windows Credential Manager, so you can inspect certificates, check expiry dates, regenerate profiles, and register devices from a Windows terminal. The runner then pulls what it needs at build time. See installing the CLI for the Windows install path.

# From Windows PowerShell: what do I have, and what is about to expire?
hexsign certificates list
hexsign certificates expiring

# Generate a CSR without OpenSSL and without a Mac
hexsign csrs generate

# Register a test device, then regenerate the profile that covers it
hexsign devices create
hexsign profiles regenerate <id>

A realistic first setup

1. 1

   Enrol in the Apple Developer Program

   From your browser on Windows. $99 USD per year. Allow a few days if Apple asks for organisation verification.

2. 2

   Create a private key and CSR with OpenSSL

   OpenSSL on Windows generates both. Upload the CSR to the Apple Developer portal and download the issued certificate.

3. 3

   Combine the certificate and key into a .p12

   Also OpenSSL, also on Windows. This is the portable bundle your CI runner will import.

4. 4

   Register your app's Bundle ID and create a provisioning profile

   Both are portal operations. Pick an App Store distribution profile if you intend to ship, or Ad Hoc for direct device installs.

5. 5

   Wire up a macOS CI runner

   Point it at your repository, give it the .p12 and profile through your CI's secret storage or a managed vault, and let it produce the signed .ipa.

6. 6

   Upload to TestFlight

   The runner can do this in the same job. From then on you manage testers from a browser on Windows.

Common questions

Can I use Xcode on Windows?

No. Apple has never released Xcode for Windows and there is no compatibility layer that works reliably. Anything claiming otherwise is either a cloud Mac with a browser front end or not Xcode.

Does Flutter or React Native change this?

Only for the writing and Android halves. You develop and test on Windows and Android freely, but producing the iOS build still requires macOS at the end.

Can I test on a real iPhone from Windows?

Not by deploying directly from Windows. Distribute through TestFlight or an Ad Hoc build produced by your macOS runner, and install from the iPhone.

Is a Mac mini cheaper than renting?

Often, if you build daily. A base Mac mini costs roughly the same as a year of moderate CI usage. Renting wins when builds are occasional or when you want zero maintenance.