Xcode has to build your iOS app. Apple never says it has to be your copy of Xcode.

What does Apple actually document as needing Xcode?

App Store Connect Help has one page on uploading builds, and it answers this better than any forum thread will. It carries a table with two separate columns: built using Xcode, and uploaded using Xcode. For an iOS app, an iOS app extension or a watchOS app extension, the build column says Xcode 26 or later. The upload column says Xcode 6 or later. Those are not the same number because they are not the same requirement, and almost every argument about this comes from reading one column and quoting the other.

The same page lists the routes. After you have added an app to your account you can upload a build using Xcode, Swift Playground, altool or Transporter, and upload for all target types is supported by Transporter and altool. Xcode Cloud is offered as a further option that both creates and uploads the build. What the page does insist on is a person: uploading requires the Account Holder, an Admin, an App Manager or a Developer. The first upload creates a beta version of the app, and the build has to be processed in Apple's system before it appears, with an email when that finishes. One caution about the same table. It carries a note saying that starting in 2026 you will be required to use Xcode 14 or later to upload. Read on 17 October 2026, the table still printed Xcode 6 for an iOS upload, so treat the note as the direction of travel rather than today's floor.

Apple dates the build floor somewhere else, on its upcoming requirements page. Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26. A second entry on the same page, in force since 9 September 2026, says iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later. These floors rise after every September release, so the number matters less than the habit of reading it with a date attached.

The Mac requirement is not on either page. It hides in Apple's SDK and system requirements table for Xcode, which pairs every Xcode release with the macOS versions it runs on. Xcode 27 needs macOS Tahoe 26.6 or later. Xcode 26.3 covers macOS Sequoia 15.6 up to Tahoe 26.x. That is the chain that actually costs money: Apple's floor sets an Xcode version, the Xcode version sets a macOS version, and the macOS version sets how old your Mac is allowed to be. None of this is a React Native fact, which is worth saying plainly. The same floors apply to the binary whatever produced it, so the question lands identically when you weigh Flutter against React Native.

Apple, App Store Connect Help, upload builds, read 17 October 2026

Can you get a shippable build without Xcode on your machine?

Yes, and Expo's documentation is unusually specific about where Xcode runs instead, which is the part that makes it believable. The build splits in two. The local half runs on your computer and does no compiling: the command line tool prepares credentials, optionally checks that your git index is clean, packs a copy of the repository into a tarball and uploads it to a private bucket. The remote half starts by creating a new macOS virtual machine for the build, fresh per build, with the build tools already installed on it, Xcode and fastlane among them.

After that it reads like the checklist you would have followed by hand. Install dependencies. Run a project doctor. Create a keychain and import the distribution certificate, write the provisioning profile into place and check that the two match. Generate the native directories if the project does not commit them. Run the CocoaPods install. Write the provisioning profile identifier into the Xcode project. Then run fastlane's build step and upload the archive. Xcode is doing exactly what it would do on your desk. The only difference is whose electricity bill it lands on.

Which Xcode is a fair question, because Apple's floor is a version number. Expo publishes the image contents on its build server infrastructure page, last modified 8 October 2026. The image carrying the latest alias is named for what is on it: macOS Tahoe 26.6 with Xcode 27.1, alongside pinned versions of Node, fastlane, CocoaPods and Ruby. That clears Apple's floor of Xcode 26 without you doing anything, and it is the argument for a hosted build that nobody makes loudly enough. Version floors are a maintenance job, and this is one you have handed to somebody whose job it is.

The upload is the same story. Expo's page on submitting to the Apple App Store, last modified 12 October 2026, states that its submit command works on macOS, Linux and Windows, so you do not need a Mac to ship iOS builds. The build lands in TestFlight after processing, usually ten to fifteen minutes. Releasing to production means signing in to App Store Connect and submitting for review, which is a web form. What you do still need, Xcode or not, is a paid Apple Developer membership, a bundle identifier in your app configuration and an app record in App Store Connect. Those are account chores. No toolchain removes them.

Expo, the iOS build process, last modified 5 May 2026, read 17 October 2026

So what do you give up by never installing it?

Three things, and only one of them is felt daily. The first is the iOS Simulator. Expo's guide, last modified 16 October 2026, says the Simulator can only be installed on macOS, and sets out the three steps: install Xcode from the Mac App Store, install the Command Line Tools from the Locations pane of Xcode settings, then add the iOS platform under Components and Platform Support. Without a Mac the documented options are a physical iPhone or Expo's remote simulator service, and that service is described on its own page as a limited access preview, not included with paid or free plans and currently open only to selected partners. Do not plan around it yet.

The physical iPhone route is the one that quietly got narrower, and it is worth knowing before you promise anyone a free afternoon. The old answer was that you install Expo's sandbox app from the App Store, scan a code and skip the toolchain entirely. Expo's own troubleshooting page, last modified 3 September 2026, now says the App Store copy of that app stops at SDK 54 and that SDK 55 and later are not available there. The build images on Expo's own servers are already aliased up to SDK 58. On a current project the documented route is to build the sandbox app yourself with the command Expo provides and distribute it through your own TestFlight internal team, which needs an Apple Developer Program membership. Apple's own enrolment page, read 17 October 2026, prices that at 99 US dollars per membership year, says prices may vary by region and are shown in local currency during enrolment, and offers a fee waiver to nonprofits, accredited educational institutions and government entities that meet its requirements. So the escape from Xcode is real and the cost did not disappear. It moved, from a Mac you buy once to a membership you renew, and you were going to need that membership to ship anyway.

It is worth knowing what the simulator is not, before you buy hardware for it. Expo lists the hardware it cannot give you: audio input, barometer, camera, and motion support, meaning the accelerometer and the gyroscope. Anything that touches those needs a real phone, with or without Xcode. If your app photographs something, records something or cares which way up it is, the simulator was never going to be the thing that told you it worked. One small current detail: on Xcode 27 the Simulator application is replaced by Device Hub, so the command that opens it changes name.

The second thing is hands-on native work. Expo is direct about this in its own comparison of when to use the hosted build service: debugging native code locally is the single row marked as not what it is for. If you are stepping through Swift or Objective C, reading a crash in a native frame or changing build settings in the project editor, you want Xcode and you want it locally. The honest point for most readers is that owning a generated app and never doing this is a perfectly normal career.

The third is running the real build steps yourself, which Expo supports through a local flag and documents the limits of, last modified 13 October 2026. You become responsible for the environment: Node and your package manager, fastlane and CocoaPods for iOS, the Android SDK and NDK for Android. macOS and Linux are supported and Windows is not officially supported or tested. You also lose things you may not have noticed: you can only build one platform at a time, caching is not supported, the version pins in your build configuration are ignored, and environment variables marked secret are unavailable. It is a debugging tool, which is how Expo frames it, and not a cheaper build. Keeping a current Xcode means keeping a current macOS, which is its own afternoon on a machine you did not buy for this. That belongs in what an app costs to maintain, and it is one of the few lines there you are allowed to decline.

Expo, the iOS build process, for what runs locally and what does not

Does any of this change because a builder wrote the project?

Two ways, one in your favour and one not. In your favour: Newly generates a real React Native and Expo project you own, uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. So the two steps Apple's rule actually lands on, compiling the binary with a recent Xcode and getting it into App Store Connect, are done before you have decided whether to install anything. It has two way GitHub sync, so the code sits in your own repository and the day you do want Xcode you clone and open. It is $25 a month, with no free plan.

Not in your favour: nobody can press submit for you. App Store Review Guideline 4.2.6 rejects apps created from a commercialized template or an app generation service unless they are submitted directly by the provider of the app's content. That is you, which is why Newly uploads the build but does not submit it. The good news is that submitting is a web form and a role on an account, not a toolchain, so this costs you an afternoon in App Store Connect rather than a Mac.

One thing to check rather than assume: whether there is an ios directory in your repository at all. Expo documents a pattern it calls continuous native generation, where the native ios and android directories are produced from your app configuration during the build instead of being committed, which is why the remote build runs a prebuild step before installing pods. On a project set up that way, going looking for a workspace file to open in Xcode finds nothing, and that is configuration rather than damage. Running the prebuild command generates the directories locally whenever you want them. The reason it matters is that advice written for a hand-started iOS project assumes those files exist and have been edited, so following it on a generated project produces changes that the next build overwrites.

All of which rests on one prior question, worth settling before you plan anything around the repository: the project is only yours to clone, open and keep if the licence says so. Read who owns AI generated code first. A toolchain decision you can reverse in an afternoon. A codebase you cannot take with you is a different kind of problem.