Apple only sells its build tools for its own computers. Xcode runs on macOS, and the certificates that prove an app is really yours are usually created on that same machine. That is the whole reason people believe an iPhone app needs a Mac, and it is why the question comes up on every forum.
It has an answer. A cloud build service runs the Apple part on Apple hardware and hands you back a finished iOS app. Expo states plainly that its submit step runs on macOS, Linux and Windows, so a Windows or Linux machine can build and ship. This guide covers what that gets you, what it does not, and the parts that are still yours: an Apple developer account, a real iPhone to test on, and the final submit button.
QUICK ANSWER
Can you build an iOS app without a Mac?
Yes. The Mac requirement comes from Xcode and Apple code signing, and a cloud build service runs both on Apple hardware for you. From Windows, Linux or a Chromebook you can produce a real iOS app and upload it to App Store Connect. You still need your own paid Apple developer account, and you still press submit yourself.
Five things to settle before you start
Every one of these is outside the build tool. Sorting them out first is the difference between a two-hour release and a two-week one, because two of them involve waiting on someone else.
- A paid Apple developer account in your own name: Apple will not accept an App Store build without one. Apple's enrolment page said on 2026-08-16 that the Apple Developer Program is 99 USD per membership year, with prices varying by region. Treat that as a figure to re-check, not a fixed price. Individuals need an Apple Account with two-factor turned on and their legal name on it. Companies additionally need a legal entity, a D-U-N-S number and a working company website, and that verification is the part that takes days.
- A real iPhone, or a person who owns one: There is no simulator in this workflow. You test by installing the app on an actual iPhone, either through a preview on your phone while you build or through a test build once you have an account. If you do not own an iPhone, line up somebody who does before you start, because the first thing you will find is a layout problem you cannot see on a laptop.
- A decision about whether you need a store app at all: A responsive web app opens on every phone, needs no developer account and no review. If your idea is a booking form, a dashboard or a portal, the web version may be the whole product. Choose the store only when you need an icon on the Home Screen, push notifications through the store channel, or the credibility of a listing.
- Names that are hard to change later: Your app needs a bundle identifier in reverse-domain form, such as com.yourcompany.yourapp, and a display name. The identifier is effectively permanent once an app exists in App Store Connect under it. Pick it deliberately, using a domain you actually control.
- A backend the app can reach from outside your network: A phone is a different machine from your laptop. It cannot see localhost, and it cannot see a port that only exists on your development server. The app has to point at a public address over HTTPS. On Playcode this is already true because the project is published on its own link, but if you assembled the pieces yourself, check it before you build.
Four ways to get an iOS build without owning a Mac
These are genuinely different trades, not four names for the same thing. The first two produce a real store app. The third avoids the store entirely. The fourth is the honest fallback when your app needs something the others cannot do.
| Approach | Best for | Tradeoff |
|---|---|---|
| Cloud build service | Anyone on Windows, Linux or a Chromebook who wants a real App Store build without buying hardware. | You are dependent on a build queue and on the service supporting your libraries. Anything with unusual native code has to be checked before you commit to it. |
| A rented Mac in the cloud | Teams who need to open Xcode itself, debug native crashes, or use a tool that has no cloud equivalent. | It is a monthly cost per person and you now maintain a second computer, including the Xcode upgrades. Most people who try this end up only using it for the two hours a year they need Xcode. |
| A web app on the Home Screen, no store | Products where the job is a form, a dashboard, a portal or a booking flow, and the audience arrives from a link. | No App Store listing, no store search, and the platform features available to a web app are narrower than a store app. You trade reach and credibility for zero accounts and zero review. |
| Buying a Mac | A team shipping iOS continuously, or an app whose core feature is a native capability that cloud builds cannot exercise. | It is the largest up-front cost and it solves a problem most first apps do not have. It is the right answer eventually for a native-heavy product, and the wrong first purchase for a first release. |
Recommended:Start with the cloud build. It is the only option that costs nothing extra to try and still ends with a real app you can submit. Move to a rented or owned Mac only when you hit a specific thing the cloud build cannot do, and be able to name that thing.
How to build and ship an iOS app without a Mac
Open the Apple account, build the app on a non-Apple computer, test it on a real iPhone, run the cloud iOS build, and upload it to App Store Connect yourself.
STEP 01
Open the Apple developer account first
It is the only step with a queue in it, so start it on day one and do everything else while it is verified.
Enrol at Apple's developer enrolment page. Use your legal name exactly as it appears on your ID. Apple states that an alias, a nickname or a company name in the name fields delays approval, and that the name you enrol under becomes the seller name shown on your App Store listing.
If you are enrolling a company rather than yourself, get the D-U-N-S number and the public company website in place before you begin. Both are checked, and both are common reasons an enrolment sits waiting.
Turn on two-factor authentication on the Apple Account you enrol with, and use an address you will still control in three years. Losing this account means losing the ability to update your own app.
Expected result: An approved Apple Developer Program membership, and the ability to sign in to App Store Connect and see an empty app list.
Verify it: Sign in to App Store Connect and create a new app record with your chosen bundle identifier. If the record saves, the account is genuinely ready.
STEP 02
Decide the one job the first version does
A first release that does one thing completely gets through review. A shell around a website does not.
Apple's App Review Guidelines set a minimum functionality bar in guideline 4.2. An app that only repackages a website, or that a user could just as easily use in a browser, is the classic rejection. Write down one complete task the app performs on the phone: signing in, capturing something, saving it, showing it back.
Write down what the user sees when it is loading, when they are offline, when the input is wrong, and when the server says no. Those four states are most of the work and they are what reviewers actually tap.
Keep the rest of the roadmap out of version one. Everything you add before the first release adds review risk without adding evidence that anybody wants the app.
Expected result: A one-paragraph description of a single complete user task, with its four unhappy states written down beside it.
Verify it: Read the paragraph to someone who has not seen the product. If they can repeat the task back and say what happens when it fails, it is specific enough to build.
STEP 03
Describe the app and let it get built
On Playcode you write the brief in plain language and get a working project with a mobile app, a backend and a database in it.
Describe the job you wrote down in the previous step, in ordinary words. Say who signs in, what they create, and what they see afterwards. You do not need to name a framework. Playcode builds the mobile app with React Native and Expo, in the same project as the web app and the backend, so one description covers all of it.
The mobile app and the web app share the same accounts and the same database, because they talk to the same backend. Somebody who signs up on your site can sign in on the phone with no extra work. That is the part most app builders cannot do, and it is the reason to keep them in one project.
Ask for changes in the same way. The point of this step is a running app, not a finished one.
Expected result: A project that contains a mobile app alongside the web app and the backend, and that runs without errors.
Verify it: Open the app preview and complete the one task end to end. If the record you create is still there after a reload, the app is really talking to its database rather than holding data in memory.
STEP 04
Set the app identity and point it at your own backend
The bundle identifier, the display name and the API address are what turn a preview into a shippable app.
Set the bundle identifier to the reverse-domain name you chose, and set the display name to what should appear under the icon. Do this before the first build, because App Store Connect ties the app record to the identifier.
Check that the app reads its API address from configuration rather than a value typed into the code. This is the single most common reason an app works in a browser preview and fails on a phone: the phone cannot reach an address that only exists on the development machine.
Add the app icon and the launch screen now. They are required for the build, and leaving them to the end is how a build fails at the last minute.
Expected result: An app that starts with your icon and name and loads real data from your published backend address.
Verify it: Search the project for a hardcoded localhost or a raw IP address in the app code. Finding none, and seeing real data on the phone, is the proof.
STEP 05
Test it on a real iPhone before you build anything
Preview it on your phone by scanning a code. This catches most problems while fixing them is still cheap.
Start the mobile preview and open it on an iPhone. There is no simulator anywhere in this path, by design. What you are checking is the things a laptop cannot show you: whether the tap targets are reachable with a thumb, whether the keyboard covers the field you are typing in, whether text is legible outdoors, and whether the app survives switching away and back.
Test on a slow connection and with the phone in airplane mode. An app that shows a permanent spinner when the network is gone will be rejected by a reviewer on hotel wifi.
If a screen breaks only on the phone, look at anything with custom native code first. Libraries that ship their own native code cannot load in a quick preview; they need a full build. Prefer a plain JavaScript alternative until you are past your first release.
Expected result: The complete task works on a physical iPhone, including the offline and wrong-input paths.
Verify it: Do the whole task on the phone with the laptop closed. Anything you have to explain away is a defect, not a quirk.
STEP 06
Run the cloud iOS build
This is the step that would need a Mac, and the step the cloud service does for you.
The build runs on Apple hardware you do not own. Expo documents that its macOS build machines run in its own macOS cloud, which is why nothing on your desk has to be a Mac.
Signing is handled in the same place. The build service can generate the certificate and the profile that prove the app is yours, after you sign in with your Apple account, and Expo's setup guide states that Apple Developer Program membership is required to build for the App Store. If you already have certificates from a previous app, you can supply them instead.
On Playcode you do not run these commands yourself. Describe what you want and the agent drives the build, asks you for the credentials it needs, and stores them as secrets in the project rather than in the chat or in a file. Never paste an Apple credential into a message.
Expected result: A finished iOS build in your build history, marked for App Store distribution.
Verify it: Open the build log and confirm it completed and produced a store binary rather than a test build. A build that succeeded but was made for internal testing cannot be uploaded to App Store Connect.
STEP 07
Upload it and press submit yourself
The upload is automatic. The submission is yours, and Apple requires that.
The upload step sends the binary to App Store Connect and works from any operating system. Expo documents that EAS Submit runs on macOS, Linux and Windows, and that you start the actual release from App Store Connect once the build has finished processing.
Nobody can submit on your behalf. Guideline 4.2.6 says apps created with a commercialised app generation service are rejected unless they are submitted directly by the provider of the app content. That is you. Playcode will draft the listing text and capture screenshots for you, but the submit button is yours to press, and the app is listed under your account.
Fill in the listing before you submit: description, keywords, screenshots at the sizes Apple asks for, a support URL, and the privacy answers. The privacy section is a questionnaire about what data your app collects, and answering it wrong is a slower problem to fix than answering it slowly.
Expected result: The build appears in App Store Connect and is attached to a version that is ready to submit for review.
Verify it: The version status in App Store Connect changes to waiting for review after you submit. Until you see that, it is not submitted.
STEP 08
Ship the second version the same way
A release process you can repeat in an afternoon is worth more than a fast first release.
Bump the version, run the build, upload, submit. Nothing about updating needs a Mac either. The one thing to keep is a note of which build number went to the store on which date, so you can tell users what they are running.
Keep the web app and the mobile app moving together. Because they share a backend, a change to the data model affects both. Test the web version after any change you made for the phone.
Watch the crash reports Apple shows you in App Store Connect after every release. The first crash of a new version usually appears within a day of it reaching real devices.
Expected result: A second release that took hours rather than days, with a recorded build number.
Verify it: Compare the build number in App Store Connect with the number in your release note. If they match, your record is trustworthy.
Test these four cases before you submit
Reviewers use apps badly on purpose, on bad networks, on devices you did not choose. These four cases are the ones that turn into rejections or one-star reviews.
| Test | Scenario | Expected result |
|---|---|---|
| happy path | On a real iPhone, sign in, complete the one task the app exists for, and close the app. | The record is saved on the server. Reopening the app shows it, and the same record appears when you sign in to the web version of the same project. |
| invalid input | Submit the main form with a required field empty, an email that is not an email, and a value far longer than the field expects. | The app explains what is wrong next to the field, keeps what the user already typed, and saves nothing. It does not crash, and it does not show a raw server error. |
| retry | Turn on airplane mode, submit the form, turn the network back on, and press the button again. | The first attempt fails with a plain message and an obvious way to retry. The retry succeeds and creates exactly one record, not two. |
| production smoke | Install the build that you actually uploaded, on a phone that has never seen the app, over mobile data rather than wifi. | A clean install signs up, completes the task, and shows the result. This is the run that catches an app pointing at a development address instead of the published one. |
What breaks, and what to do about it
Every one of these has been the whole delay for somebody. They look mysterious and they are not.
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| The iOS build fails during signing. | The Apple account is not fully enrolled, the membership lapsed, or the bundle identifier in the app does not match the app record in App Store Connect. | Open the build log and find the first error rather than the last. Then sign in to App Store Connect and compare the identifier on the app record with the one in your app configuration, character for character. | Fix the mismatch, or complete the enrolment, and run the build again. Do not create a second app record to work around it; that permanently splits your app in two. |
| It works in the browser preview and shows nothing on the phone. | The app is calling an address only the development machine can see, usually localhost or an internal port. | Open the same API address in the phone browser. If it does not load there, the app was never going to reach it either. | Point the app at the project public HTTPS address through configuration rather than a value in the code, then reload it on the phone. |
| A library fails the moment the screen opens on the phone preview. | The library contains its own native code. A quick preview can only run the native code it was built with. | Remove the screen that imports it and see whether the app starts. If it does, that library is the cause. | Swap it for a JavaScript-only alternative, or accept that this feature needs a full build to test. Decide before your first release, not during it. |
| Apple rejects the app under guideline 4.2 for minimum functionality. | The app is largely a wrapper around a website, or it repeats what the mobile browser already does. | Ask what the app does that a browser tab cannot. If the honest answer is nothing, the reviewer reached the same conclusion. | Add a capability that only makes sense on a phone, or ship the web version instead and stop paying the store tax. Both are legitimate outcomes. |
| The enrolment has been pending for over a week. | The name on the Apple Account does not match the legal identity, or the company D-U-N-S record or website did not verify. | Re-read the enrolment requirements against what you actually entered, particularly the first and last name fields and the company website. | Correct the mismatch and contact Apple Developer Support. This is a queue you cannot shorten by resubmitting, so keep building while you wait. |
| The app was accepted, but users on older iPhones report it looks broken. | The layout was only ever checked on one device size, usually a large recent phone. | Open the app on the smallest screen you can find and on the largest text size in the accessibility settings. | Fix the layout to flow rather than sit at fixed sizes, and add a small-screen device to your test list permanently. |
Deploy, monitor, recover
Deploy
Keep the version number and the build number in the project, not in your head. Every upload to App Store Connect needs a build number that has never been used before.
Release one change at a time when you can. When something breaks after a release with six changes in it, you have six suspects.
Use a test build for the people who will tell you the truth before the store version goes out. The submit documentation describes the build reaching the beta testing channel once Apple finishes processing it.
Monitor
Read the crash reports in App Store Connect after each release. A crash rate that rises the day after a release is the release.
Watch your backend errors at the same time. The mobile app and the web app share it, so an error caused by the phone shows up in the same place.
Track how many people finish the one task the app exists for, not how many downloaded it. Downloads say the listing works. Completions say the app works.
Recover
Keep the previous build. If a release is bad, the fastest honest recovery is a new build with the fix, because you cannot un-ship what people already installed.
If the failure is on the server rather than in the app, fix it there. That reaches every installed copy immediately without going through review at all, which is a good reason to keep logic on the backend.
Take a snapshot of the project before a risky change so you can restore code, files and database together and try again.
Security and account safety
Most of the risk in this workflow is not in the code. It is in the credentials and in who owns the account the app lives under.
- The Apple developer account must be in your name or your company name, never a contractor personal account. Whoever holds it controls your ability to update the app.
- Store Apple and build-service credentials as project secrets, never in chat messages, code or a committed file. A credential that has been pasted into a conversation should be treated as leaked and replaced.
- Prefer a scoped App Store Connect API key over an Apple ID password for automated uploads, and remove the key when the person who created it leaves.
- Never ship an API key that is meant to be private inside the app. Anything in an app bundle can be read by anyone who downloads it. Keys belong on your backend, which is one more reason for the app to talk only to your own server.
- Turn on two-factor authentication for the Apple Account and the build-service account, and record who has access, so an audit is a lookup rather than an investigation.
- Answer the App Store privacy questionnaire from what your app actually collects, not from what you intend to collect later. An inaccurate answer is a compliance problem after the app is live.
Questions people ask about building iOS apps without a Mac
Can I really develop an iOS app on Windows?
Yes. You write the app on Windows and a cloud service runs the Apple-only part on Apple hardware, then hands back an installable iOS app. Expo documents that its submit step runs on Windows and Linux as well as macOS. The only thing you cannot do from Windows is open Xcode itself.
Do I still need an Apple developer account?
Yes, and there is no way around it. Apple requires a paid Apple Developer Program membership to build for the App Store and to distribute test builds. Nobody can lend you theirs, because the app is published under the account of whoever owns the content.
What does the Apple developer account cost?
Apple listed the Apple Developer Program at 99 USD per membership year on its enrolment page when we checked it on 2026-08-16, and stated that prices vary by region. Google Play charged a 25 USD one-time registration fee on the same date. Both are Apple and Google charges, not ours, and both can change, so check the current figure before you budget.
Can I test the app on an iPhone without a Mac?
Yes. You preview it on your phone while you build, and once you have a developer account you can install a test build the same way any beta tester does. There is no iPhone simulator in this path, which is a feature rather than a gap: everything you test is what a real device does.
Does Playcode publish the app to the App Store for me?
No, and no honest tool can. Playcode drives the build, drafts the listing and captures screenshots, but you need your own Apple and Google developer accounts and you press the final submit yourself. Apple guideline 4.2.6 requires apps made through a service like ours to be submitted by the owner of the content.
How long does App Review take, and will my app be approved?
Nobody can promise either. Review takes days rather than minutes and it can come back with a rejection, most often for minimum functionality. Plan for at least one round trip, and read Apple's guidelines before submitting rather than after being rejected.
Do I get an Android app too?
Yes. The same project builds for both, because the app is written once with React Native and Expo. Android has its own account and its own store rules, and Google charges a separate one-time registration fee, but you are not writing the app twice.
Do I own the code, or am I locked in?
You own it. Playcode produces real, exportable code and the project contains the mobile app, the web app and the backend together. If you later decide you want a Mac and Xcode, you take the project with you.
Should I build a mobile app or just a website?
Build the website first if the job is a form, a dashboard, a booking flow or a portal, because there is no account, no review and no waiting. Build the app when you need an icon on the Home Screen, a store listing, or a feature that only makes sense on a phone.
Build it on Playcode
Describe your app. Build it from the computer you already own.
Playcode builds the mobile app, the web app and the backend in one project, and the iOS build runs in the cloud. You bring the Apple account and press submit.
Start BuildingNo credit card required.