The Deadline, in Plain Terms
On September 9, Apple opened App Store submissions for iOS 27, iPadOS 27, macOS 27, tvOS 27, visionOS 27 and watchOS 27. In the same announcement, Apple set a date: starting in April 2027, submitted apps must be built with the iOS 27 SDK or later. The same rule applies to iPadOS, tvOS, visionOS and watchOS apps with their own version 27 SDKs.
Founders mix up two different things here, so separate them now. The SDK is the toolkit you compile against. The deployment target is the oldest iOS version your app runs on. Apple is raising the first and not the second. You can build with the iOS 27 SDK and still support users on iOS 17 or 18, if your code does. Nobody is forcing you to cut off older phones.
What the rule does force is a rebuild with Xcode 27 and a new submission before the cutoff for any app you want to keep updating. An app that is already live is not pulled. But the first time you need to ship a bug fix after April on an app whose project still builds with an old toolchain, Apple will refuse the upload. That is a bad moment to discover your project does not compile on a new Xcode.
Apple has done this every year for a long time. The pattern is predictable, which is the good news. The bad news is that apps that skip a year of upkeep pay for it in one lump. Our breakdown of app maintenance costs explains why that lump costs more than the steady drip.
Who Is Affected and Who Is Not
Not every founder needs to read the rest of this the same way.
- You have an app in active development. Your team probably moved to Xcode 27 already or will in the next sprint. Your job is to confirm it and set a date.
- You have a live app that a contractor built and nobody touches. This is the risky group. If you have not shipped an update in a year, your project may use deprecated APIs, old dependency versions and a build setup nobody remembers. Budget for it.
- You are about to launch. Build with the new SDK from day one. It costs nothing extra and removes the problem.
- Your app is a web app in a wrapper. The wrapper still gets rebuilt. The web content does not care.
If you do not know which group you are in, open your App Store Connect page and look at the date of your last build. Then ask whoever holds your Apple Developer account whether the project still compiles on a current Xcode. If the answer is a pause, you are in group two.
A cross-platform app is not exempt. React Native, Flutter and Expo all produce a native iOS project in the end, and that project must be built with the new SDK. The framework version you use has to support Xcode 27, which sometimes means upgrading the framework first. The Expo and Flutter teams usually ship support quickly, but if you are pinned to an old release, check now. Our walkthroughs of Expo SDK migration show what a framework upgrade involves.
The Concrete Checklist
Here is what to do, in order. Most apps can finish this in a few days of work spread across a few weeks.
- Install Xcode 27 and build. Apple released the Release Candidate on September 9. Open your project and read every warning. Deprecation warnings today become errors in later releases.
- Update dependencies. Payments, analytics, push, crash reporting and ad SDKs all need a version that supports the new toolchain. Check each vendor's release notes. A single abandoned library is the most common blocker we see.
- Run your regression tests. If you have none, write a short manual script that covers sign-in, purchase, push and the three screens that earn you money.
- Test on iOS 27 and on your oldest supported version. The SDK changes how some system components look and behave when you build against it, even when users run an older OS.
- Submit through TestFlight first. Get a build processed by App Store Connect with the new toolchain. If something is wrong with signing or entitlements, you want to learn it in October, not April.
- Ship it. Release the rebuilt version as a normal update. There is no reason to hold it until the deadline.
The fifth step is the one people skip. A build that compiles locally is not a build that passes processing. Signing certificates expire, provisioning profiles go stale and entitlements drift. Finding that out the week before a deadline, when you also have a bug to fix, is what turns a routine rebuild into a crisis.
Two Smaller Changes That Will Bite If You Miss Them
The SDK deadline gets the attention, but Apple's recent developer news contains a few smaller items that cause real bugs.
Sign in with Apple has a new relay domain
On August 24, Apple said Sign in with Apple will issue new private relay addresses on private.icloud.com. Existing addresses on privaterelay.appleid.com keep working. If your app sends email to users who hid their address, your email validation, allowlists and any transactional email provider rules must accept both domains. If you validate emails against a fixed domain list, new sign-ups will fail silently or bounce. The fix is a one-line change plus a test, and the failure mode is lost users, so do it this month.
A new alternative tracking prompt in the EU
Starting with iOS 27.2, Apple lets developers use an alternative App Tracking Transparency prompt in the EU. In Germany, France, Italy, Poland and Romania, only the alternative prompt is available. Apple says the rules for when you must ask permission are unchanged. If you ship ads or attribution to European users, ask your privacy lead or lawyer whether the change affects your consent flow. If you sell in the EU, our piece on Apple's new EU App Store fees covers the other change that landed on October 1.
Mac developers have one more date. Apple said macOS 26 is the last release supporting Intel Macs and Rosetta, and macOS 27 is Apple silicon only. If you ship a Mac app, build universal binaries now or set the build architecture to arm64 only.
There is also a Developer ID certificate item for anyone distributing Mac installers outside the Mac App Store: the original Sub-CA expires February 1, 2027. Re-sign installers with the new G2 certificate before then.
What It Costs
Costs depend on how long the project has sat untouched. These are market ranges in our own estimate, using agency rates in the US and Western Europe.
- Actively maintained app, one platform: one to three days to confirm the build, update a few dependencies and test. Roughly $1,000 to $4,000, often absorbed into a normal sprint.
- App untouched for 12 to 18 months: one to two weeks. Expect deprecated APIs, outdated packages and some UI differences. $5,000 to $15,000.
- App untouched for two years or more, or built on an old framework version: two to six weeks. You are doing a modernization at that point, not a rebuild. $15,000 to $50,000, and the high end is for apps with custom native modules.
- App that cannot compile at all: this is a rebuild conversation, and the work is better priced as one.
Three things push you toward the high end: a cross-platform framework two or more major versions behind, native modules written by someone who has left, and no automated tests. All three are common in apps that were built fast to get to launch.
Compare the cost of acting now with the cost of waiting. A rebuild started in October is a planned project. A rebuild started in the first week of April, because a security fix is blocked, is an emergency with a rush premium, and it may land during your busiest season. If your app earns money, treat this as insurance. The same logic is behind our analysis of the real cost of technical debt.
Using AI Tools to Do the Upgrade
Every founder now asks whether a coding agent can just do this. It can help, with limits.
Coding agents are good at the mechanical part: replacing deprecated calls, fixing compiler errors and bumping version numbers across files. A day of agent-assisted work can clear a lot of warnings. They are weaker at the parts that decide whether the upgrade is safe: reading a vendor's migration notes, noticing that a behavior changed without a compiler error, and knowing which three flows must be tested by hand.
Our rule is simple. Let the agent do the first pass on a branch. Have a human who knows iOS review the diff. Run the full manual test script on a device before it goes anywhere near App Store Connect. And never give an agent access to your signing keys or your production account. We wrote about the guardrails in rules for AI coding agents and production access.
The biggest risk with an AI-assisted upgrade is quiet breakage. The app compiles, the agent reports success and a payment flow now fails on one OS version. That is why the regression script matters more than the tool. If you do not have one, writing it is the best use of this month.
A Timeline That Works
Apple has given you roughly six months. That is plenty if you start early and tight if you start in March. Here is a schedule we would give a founder.
- October: find out where you stand. Build once on Xcode 27, list the warnings and the blocked dependencies, and price the work. Fix the Sign in with Apple relay domain check.
- November and December: do the upgrade on a branch, ideally alongside a feature release so you pay for one QA cycle. Avoid the week of Black Friday and the last two weeks of December if you sell anything seasonal.
- January and February: ship the rebuilt version, watch crash rates for two weeks and fix the regressions.
- March: stay clear. If the work is done, you can ignore the deadline entirely, which is the point.
A word on what to tell your users and your board. Nothing visible changes for customers when you rebuild with a new SDK, so there is no announcement to make. Internally, write down the date you finished and which Xcode version built the release, and put the next check on the calendar for September. Apple opens submissions for the new OS releases every September and sets a new minimum every April, so the same task returns on a fixed rhythm. Teams that treat it as a standing yearly chore spend a couple of days on it. Teams that treat it as a surprise spend weeks, and they spend them under pressure.
The last practical point is ownership. Someone specific should hold the Apple Developer account, the signing certificates and the calendar reminder. When a contractor leaves, those three things often leave with them.
If you can only do one thing this week, build your project on Xcode 27 and see what happens. Ten minutes of effort answers the question that drives everything else. For the review side of shipping, keep our App Store rejection guide open, since a rebuilt binary with new entitlements is the sort of change that triggers a fresh look from reviewers.
If the build fails and nobody on your side knows why, or if you want an outside estimate before you commit budget, we do this work for founders often and can usually size it in one call. Book a free strategy call and bring the build log.