Build a Flutter iOS app without a Mac

Before any of the no-Mac tooling matters, a few things have to be in place. None of them require Apple hardware, but one of them costs money.

• An active Apple Developer Program membership. It costs 99 US dollars per year and is mandatory to sign apps and submit to the App Store.
• A Flutter project that already builds and runs on a simulator or an Android device. Fix your Dart errors before adding iOS to the mix.
• An app record in App Store Connect, with a unique bundle identifier such as com.yourcompany.yourapp.
• A place to run the macOS build: a cloud CI service, a rented Mac, or a managed platform. The next sections compare these.

Code signing is the step that stops most Mac-less developers, not the build itself. Apple requires every iOS app to be signed with two things: a distribution certificate that proves who you are, and a provisioning profile that ties your certificate, your app identifier, and your allowed devices together. Historically both were generated inside Xcode on a Mac, which is exactly why going Mac-free feels blocked here. The good news is that certificates and profiles are just files, and they can be created and managed without ever opening Xcode. You have two practical routes: let a cloud build service generate and store them for you through the Apple API, or automate them with a tool like fastlane match, which keeps an encrypted copy in a private git repository and reuses it on any machine. Either way, signing stops being a manual Xcode ritual.

• Managed signing: a cloud service creates and rotates the certificate and profile through Apple's API. Lowest effort, least control.
• fastlane match: your certificates live encrypted in a private git repo and are pulled into any build. More setup, fully reproducible.

There are five realistic paths in 2026. They trade cost against how much pipeline you have to configure yourself. Here is an honest comparison.

• Cloud CI (Codemagic, Bitrise): hosted macOS build machines aimed at mobile, with strong Flutter support and code signing helpers. You still write and maintain a build configuration. Best for teams who want control and repeatable CI.
• GitHub Actions macOS runners: run flutter build ipa on Apple hardware inside your existing GitHub workflow. Cheapest at low volume, but you assemble the signing and upload steps yourself. Best for developers already living in GitHub.
• Rent a Mac in the cloud (MacinCloud and similar): a full remote macOS desktop you control by the hour or month. Maximum flexibility and maximum manual work, because you are still doing Xcode steps by hand. Best for occasional one-off builds.
• Dedicated CLI tools (Appollo, Odevio): command line tools that push your Flutter project to a remote Mac and return an .ipa. Simpler than raw CI, but another vendor in the chain. Best for solo developers who want one command.
• A managed release platform (Releasely): you upload your build or project in a web workspace, and the platform handles the iOS build, the code signing, and the App Store submission for you. No CI file to maintain and no macOS to configure. Best for developers who want to ship, not to run a pipeline.

Here is the end to end path, with a note on where each step runs so you always know what needs macOS and what does not. If you want to weigh every option first, see our comparison of app release tools.

1. Confirm your Flutter project builds cleanly on your machine, on Windows or Linux.
2. Enroll in the Apple Developer Program, then create the app record and bundle ID in App Store Connect, from any browser.
3. Set your version and build number in pubspec.yaml before you cut the build, on your machine.
4. Generate or connect your distribution certificate and provisioning profile, through a cloud service or fastlane match, with no Mac.
5. Run the iOS build to produce a signed .ipa, on cloud macOS rather than your machine.
6. Upload the .ipa to App Store Connect and let it process into TestFlight, through your cloud service.
7. Fill in your store listing, screenshots, and metadata, then submit for review, from any browser.

Being honest about the limits keeps you out of trouble. A few things are harder or impossible without access to macOS or a physical Apple device.

• Running the iOS Simulator. The simulator is macOS only, so you cannot use it from Windows or Linux.
• Live debugging on a physical iPhone from your editor usually expects a Mac, though TestFlight lets you install and test builds on your own device without one.
• Some native plugins with custom iOS build steps may need manual Xcode work, best done on a rented cloud Mac.

For day to day iteration, most teams test on Android locally and rely on TestFlight for real iOS device testing.

Yes. You write and manage everything from Windows, and the actual iOS build and upload run on a cloud macOS environment. From your side it can be a single push or a single upload, with no Apple hardware involved.

Usually yes, in some form. Cloud CI services and rented Macs bill by build minutes or by the hour, and a managed platform bundles the cost into its plan. Free GitHub Actions minutes can cover very low volume. The one unavoidable cost is the Apple Developer Program at 99 dollars per year.

No. Apple requires that iOS apps are built and signed with its toolchain, but it does not require that you own the Mac running it. Using a cloud macOS machine or a managed service is fully compliant, which is why every major mobile CI provider offers it.

Yes, through TestFlight. Once your build is processed in App Store Connect, you can install it on any iPhone from the TestFlight app and test the real iOS build. What you cannot do without macOS is run the iOS Simulator or attach a debugger from your editor.