How to Submit an App to the App Store Without a Mac
Contents
Last updated: August 2026.
You can submit an app to the App Store without owning a Mac, but be precise about what that means: Apple's code-signing tools still only run on macOS somewhere. What you're avoiding is buying and maintaining your own Mac, not macOS itself, which shows up on a cloud machine in every method below except the ones that hide it from you entirely.
Why this is a barrier at all
Every iOS app has to be cryptographically signed with a certificate generated through Apple's own tooling before it can install on a device or reach the App Store. That signing step has historically required Xcode, and Xcode is Mac-only. Windows and Linux users, and plenty of Mac users who'd rather not deal with Xcode, have been stuck with that requirement since the App Store existed. In 2026, that's no longer a hard stop, just a step that happens somewhere other than your own computer.
Four real paths, least to most hands-off
Rent a cloud Mac. Services like MacinCloud give you remote access to an actual Mac, and you run Xcode on it yourself the same way you would locally. This is the most manual option and the closest to the old workflow, useful if you already know Xcode and just don't own the hardware.
Use a CI service with hosted Mac runners. Codemagic, Bitrise, and GitHub Actions with macOS runners all spin up a real cloud Mac (often literally a Mac Mini instance) when you push code, build the app, handle certificates and provisioning automatically through an App Store Connect API key, and upload straight to App Store Connect. You write a config file once and never touch a Mac directly. This is the standard path for developers comfortable with Git and CI pipelines.
Use Expo's EAS Build and Submit, if you're on Expo or React Native. eas build --platform ios builds on Expo's own cloud Mac fleet and handles code signing for you, and eas submit uploads the finished build to App Store Connect, both from a plain terminal command that runs on macOS, Linux, or Windows. Expo's own documentation is explicit that this removes the Mac requirement entirely for their stack.
Use a no-code or AI platform that handles the whole pipeline. Huxly and similar tools fold certificate generation, building, and App Store submission into the product itself, so there's no CLI, no config file, and no cloud Mac to manage even indirectly. This is the least technical option and the one most first-time builders want.
What you need no matter which path you pick
An Apple Developer Program membership, $99 a year, is non-negotiable regardless of method, and signing up for it doesn't require a Mac either, it's a web form. You'll also need a unique bundle identifier for your app and, before submitting for full review, it's worth putting a build on TestFlight and installing it on your own phone. Internal TestFlight testing doesn't require Apple's review, so it's the cheapest way to catch an embarrassing bug before a reviewer does.
Step by step, the no-code path
- Sign up for the Apple Developer Program ($99/year) from any browser, no Mac needed for this step on any path.
- Build your app in a tool that handles native compilation and signing for you.
- Preview the app, ideally on a real device or a live simulator, before moving toward submission.
- Let the tool generate certificates and a provisioning profile, on platforms built around this, it's usually one click rather than a manual setup.
- Push the build to TestFlight first and install it yourself, or send it to a few testers, before submitting for full review.
- Submit for App Store review once you've caught the obvious issues in TestFlight.
Common gotchas
Duplicate build numbers get rejected. Apple requires a unique build number on every upload, if you fix a bug and re-upload without incrementing it, the upload fails outright.
CI-based paths need an App Store Connect API key, not just your Apple ID login, that key (a Key ID, Issuer ID, and private key file) is what lets an automated service authenticate with Apple on your behalf.
Screenshots are still required for specific iPhone sizes (6.9-inch and 6.5-inch as of 2026) and for iPad if your app supports it, regardless of which build method you used.
For the fuller cost picture across every build approach, see our breakdown of what it costs to build a mobile app in 2026, and for a wider look at getting started without coding at all, see how to build a mobile app without knowing how to code.
FAQ
Do I really never need to touch a Mac at all?
With a CI service, an EAS-based workflow, or a no-code platform that handles building and signing for you, no, you never interact with a Mac directly. A cloud Mac is still doing the compiling and signing somewhere in the chain, you're just not the one operating it.
Is renting a cloud Mac different from using a CI service?
Yes. Renting a cloud Mac (MacinCloud and similar) still means you run Xcode yourself remotely. A CI service like Codemagic automates the build and signing for you based on a config file, so you're not operating Xcode at any point.
Can I submit an iOS app from Windows or Linux?
Yes. Expo's EAS Submit explicitly works on macOS, Linux, and Windows. CI services and no-code platforms are also fully cross-platform since the build happens on their infrastructure, not your machine.
Do I still need an Apple Developer account if I use a no-code tool?
Yes, always, regardless of build method. It's $99 a year, and signing up doesn't require a Mac, it's done entirely through Apple's website.
What's the easiest path if I'm not technical at all?
A no-code or AI platform that handles certificates, building, and submission internally. CI services and EAS both still involve some command-line or config-file work, which is fine for a developer but a real barrier if you've never used Git or a terminal.
Why did my build get rejected before it even reached review?
Usually a duplicate build number from re-uploading without incrementing it, or a missing required screenshot size. Neither is a review judgment call, they're automated checks that happen before a human reviewer sees the app.
Should I test on TestFlight before submitting for full review?
Yes. Internal TestFlight testing skips Apple's review process entirely, so it's the fastest way to catch a bug on a real device before you burn a review cycle on it.
