A new iOS changes nothing about your live app. The deadline arrives in April.
When Apple ships a major iOS version, the app you already published keeps running and keeps selling, and you are not asked to rebuild it that week. Apple writes its minimum requirements about apps uploaded to App Store Connect, and the new one does not take effect for months. The version released in September 2026 was iOS 27, with Xcode 27 alongside it, and the requirement to build against that SDK starts in April 2027. What does change immediately is who your code is running on, because your users update long before you do. Every date on this page comes from Apple's and Expo's own documentation, read on 16 October 2026.
What follows is which of Apple's requirements are in force today, which are only announced, what the rebuild actually involves on an Expo project, and what is worth testing before you ship it. Then the trap: the page Apple calls Upcoming Requirements is not where the upcoming requirement is.
Start with what happens on release dayThe short version
One rebuild a year, due seven months after the launch.
A major iOS release gives you three jobs and one of them has a date. Test the app you have on the new version, because that is where your users now are. Move the project to the new SDK at some point over the winter. Ship the rebuild before Apple starts refusing uploads built with the old one. The first job is urgent and the third is dated. The middle one is yours to schedule, which is why it so often does not get scheduled at all.
Nothing here is enforced against an app that is simply on sale. The requirement bites at the moment you want to ship something, which is usually the moment you can least afford a toolchain detour. Doing the upgrade in a quiet week in January is the whole trick, and it is the most predictable item in what an app costs to maintain.
Does a new iOS break the app you already shipped?
No, and it is worth being precise about why. The binary on somebody's phone is the binary you uploaded. It is not recompiled, it does not get a new SDK, and Apple's minimum requirements are all written about apps uploaded to App Store Connect. An app that is sitting on the store, selling, with nobody touching it, is not in scope for any of them. The listing does not change either.
What changes on release day is the population your code runs on. Phone owners take a free OS update far faster than any developer moves a project, so a version that did not exist last month is running a real share of your installs while you are still reading the release notes. Anything that was already fragile now fails in front of more people. That makes the first fortnight after a major release the time to read your error reports properly rather than the time to rebuild. If something does start crashing, the useful skill is debugging a crash from a stack trace you did not produce yourself.
The second thing that arrives with a major OS is usually hardware, and hardware is what quietly ages a listing. Apple's page for submitting apps said, on 16 October 2026, that iPhone Duo would be available from 23 October and that app submissions were already open. A new device means a new screen to lay out for and, when Apple adds a required size, a new set of store screenshots. None of that is enforced on the app you have shipped. All of it is waiting in the next submission.
Apple, submit your apps and games today, read 16 October 2026
Work out your own case
Do you have to rebuild yet?
Pick what you are actually trying to do. The answers use the dates Apple has published, read on 16 October 2026.
No upgrade needed
The minimum in force is the one from last April: Xcode 26 and an SDK for iOS 26. A build that already meets it uploads today exactly as it did in August. Nothing about iOS 27 stands between you and a one line fix.
Dates move once a year. Check Apple's own page before you plan around any of them.
When does Apple actually require the new SDK?
The following spring. Apple's page for submitting apps, read on 16 October 2026, says that starting April 2027, apps and games uploaded to App Store Connect need to meet a set of minimum requirements, and the first one is that iOS and iPadOS apps must be built with the iOS and iPadOS 27 SDK or later and target iOS 15 or later. The same list names the tvOS 27, visionOS 27 and watchOS 27 SDKs for those platforms. So on the day iOS 27 shipped, nothing about your toolchain stopped working. You had about seven months, and in mid October 2026 you still have six.
The requirement actually in force is the one before it. Apple's Upcoming Requirements page in Developer News, read the same day, lists it under the heading SDK minimum requirements and dates it "Since April 28, 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. Look at the dates Apple has used for the same requirement in other years, 25 April 2023 and 29 April 2024, and the shape is clear. It lands in late April, every year, about seven months after the OS it names.
Two details in that wording are worth more than the date. First, Apple says uploaded to App Store Connect, not submitted to the App Store. A TestFlight build is an upload, so expect it to clear the same floor as a release. Second, there is a separate clause about the version you target, and it moves on its own schedule. Since 9 September 2026, iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later. From April 2027 that becomes iOS 15 or later. Building with the newest SDK and supporting back to an old floor are different settings, and only one of them affects which phones can install you.
Here is the trap. The page Apple calls Upcoming Requirements is not where the upcoming requirement lives. Every entry on it, all twenty on the day we read it, begins with the word Since, because the page is a record of what has already started. The April 2027 minimum is not on it. It is on the page about submitting apps, in prose, under a heading about updating for the latest OS releases. If you have ever checked Upcoming Requirements, found nothing new and concluded you were safe, that is why.
Apple, submit your apps and games today, read 16 October 2026
The dates Apple has actually published
Read on 16 October 2026. Apple revises these once a year, so the right column is the one to check again before you plan a release around it.
| Requirement | What Apple prints | Blocks an upload today |
|---|---|---|
| Built with Xcode 26 and an SDK for iOS 26 | Since 28 April 2026 | Yes |
| Targets iOS 13 or later | Since 9 September 2026 | Yes |
| Built with the iOS and iPadOS 27 SDK or later | Starting April 2027 | No |
| Targets iOS 15 or later | Starting April 2027 | No |
| Rebuilt because iOS 27 shipped | No date, Apple asks you to test rather than rebuild | No |
What do you actually change in the project?
On a React Native app built with Expo, you do not go hunting through an Xcode project. You move the Expo SDK version and let it move the native side for you. Expo's upgrade guide, read on 16 October 2026, gives four steps. Install the new expo package. Run npx expo install --fix to pull every dependency to the version that matches, then npx expo-doctor to find the obvious problems. Update the native projects. Read the changelog for the version you are moving to, including the section at the bottom of the release notes called Upgrading your app, which carries the instructions specific to that release.
Step three splits two ways. If the project uses Continuous Native Generation, which means the ios and android folders are generated rather than kept, you delete those folders and the next build recreates them against the new SDK. That is the cheap path, and it is why generated projects tend to survive this better than hand-maintained ones. If the project does keep its own native folders, you run npx pod-install and apply the relevant changes from Expo's native project upgrade helper by hand, which is the part that turns an afternoon into a week.
Expo is explicit about doing this in small steps: it recommends upgrading SDK versions incrementally, one at a time, so that when something breaks you know which version broke it. The current release on 16 October 2026 was Expo SDK 58. Expo also notes that Expo Go only supports the latest SDK version, with older ones no longer supported, which is why it points production apps at development builds instead. A project four versions behind is not four times the work. It is a different and worse job, because the tools that would have helped you no longer run it.
The Xcode half is simpler than it sounds. The SDK ships inside Xcode, so meeting a requirement for the iOS 27 SDK means building with Xcode 27, which arrived in September 2026 alongside the OS. If a hosted build service compiles for you, the version of Xcode it uses is its decision, not yours, and that image is usually upgraded on its own timetable. Check which one your builds are using before you assume the requirement is met.
What is worth testing before you ship the rebuild?
Everywhere your app asks the operating system for something. Camera and photo access, notifications, location, sign in, the payment sheet, deep links, anything that keeps running when the app is in the background. Those are the seams a major release moves, and they tend to fail quietly rather than crash: a prompt that no longer appears, a permission that comes back denied, a link that opens the wrong screen. A smoke test that only checks the app launches will miss all of it. Apple's own instruction on the submission page is the plain version of this: make sure your apps and games work as expected on devices running the latest OS releases.
Read changelogs in two directions. Apple tells you what the OS changed. Expo's per version release notes tell you what the upgrade changed underneath you, which on a React Native project is usually the bigger list, because a single SDK bump carries a new React Native version and dozens of library versions with it. The crashes that follow an SDK upgrade mostly come from your own dependencies, not from Apple.
Then ship it where you can still take it back. Put the rebuild in front of real testers on the new OS for a few days before it goes to review, because a simulator will not reproduce an expired token, a slow network or a four year old phone. On the Android side, send the same rebuild out as a staged rollout on Google Play so a small share of users sees it first and you can halt it. Then watch your error reports for a week. An annual SDK upgrade touches more of the app than any feature you will ship that year, and it deserves to be released more carefully than one.
Where this lands if a builder generated your app
The question to ask about any app builder is not whether it can do the annual upgrade. It is whether you could do it without the builder. If the project only exists inside somebody's hosted editor, the April deadline is their deadline, and you find out whether they met it when you try to ship a fix.
Newly generates a real React Native and Expo project that you own, with two way GitHub sync, so the SDK bump is an ordinary change in a repository on your account. You can describe it to the agent, or open the repository and do it by hand, or hand it to a developer for an afternoon. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. Newly is $25 a month and there is no free tier.
One limit is worth stating plainly, because it is the same limit every builder has. Newly does not submit to the App Store for you. App Store Review Guideline 4.2.6, read on 16 October 2026, rejects apps created from a commercialized template or app generation service unless they are submitted directly by the provider of the app's content, so the account, the submission and the April deadline are yours. That is also why the annual rebuild travels with the app rather than with the tool, and why it is one of the obligations that come up when transferring an app to another account.
Questions people ask when iOS gets a major update
Not by itself. The build people have on their phones is the build you uploaded, and Apple's published minimums are written about apps uploaded to App Store Connect, not about apps already on sale. What changes on release day is the mix of devices your code runs on, because users update faster than developers do. A bug that only appears on the new version quickly becomes most of what you see in crash reports, so the first week after a major release is a week to watch, not a week to rebuild.
Put the upgrade in the calendar, not in the inbox
Pick a week in the winter, move the SDK, test the seams, ship it carefully. Done on your own schedule it is a quiet afternoon. Done in April with a customer waiting on a fix, it is the worst week of the year.
Start building