It's May 2027 and your app's urgent fix won't upload. A pre-mortem on Apple's April SDK deadline

The story, told from May 2027

This is a pre-mortem, so it starts with something that hasn't happened. Imagine it's a Tuesday in May 2027. A customer emails to say the booking screen in your iPhone app shows last year's opening hours, and the fix is a single line. Your developer changes it, builds the app on the same laptop they used last summer, and uploads it to App Store Connect.

The upload is rejected. Since April, Apple has required iOS and iPadOS apps to be built with the iOS & iPadOS 27 SDK or later, which means Xcode 27, and to target iOS 15 or later. The laptop has Xcode 26. Updating Xcode brings a list of warnings and two errors from a third-party library that hasn't been touched in a year. The one-line fix takes three weeks, and for those three weeks the app keeps showing the wrong hours.

Nothing in that story is anyone's fault in particular. Deadlines like this rarely break an app. They break the day you need to change it. The rest of this note works backwards through why the story happens, and what to do in the next five months so it doesn't.

What Apple actually requires, and when

Three dates matter, and two have already passed.

Since April 28, 2026: uploads must be built with Xcode 26 or later, using an SDK for iOS 26 or the matching version for Apple's other platforms.

Since September 9, 2026: iOS and iPadOS uploads must target iOS 13 or later.

From April 2027: iOS and iPadOS uploads must be built with the iOS & iPadOS 27 SDK or later and target iOS 15 or later. Apple's submitting page says to build and test with Xcode 27.

Two things soften this. First, it only applies to uploads, new apps and new versions. An app already on the App Store doesn't stop working in April. Second, the iOS 15 minimum is less of a jump than it sounds. The Mac Observer points out that Apple's own Xcode support page already lists iOS 15 as the lowest deployment target for Xcode 26 and Xcode 27. If you've uploaded an update since April 2026, your app very likely targets iOS 15 already.

So the real change in April is the build tool. That's why it catches the apps that aren't updated often.

Why the story happens

Working backwards from the rejected upload, there are usually four causes, and most apps have at least two.

The app is "done." It works, customers use it, and nobody has opened the project since the last release. Apps built for a specific job, a booking app, a field service app, a loyalty app, often go months between updates. Each month makes the first build with new tools a little harder.

Nobody owns the build. The person who knows how to build and upload the app may be a freelancer, a former employee or an agency you stopped working with. The Apple developer account might be in their name. We wrote about the same problem on the Android side in who holds the Android signing key, and it applies here just as much.

Third-party code lags. Most apps include libraries from other companies: payments, maps, analytics, barcode scanning, chat. If one of them hasn't shipped a version that builds cleanly with Xcode 27, you're waiting on them, or replacing it.

The fix is urgent when the deadline is discovered. Nobody upgrades tools for fun. The first time anyone notices the April rule is the day a fix has to ship, which is the worst possible day to find out.

What to do between now and April

None of this is hard, but it has to be done before you need it.

Open the project this year. Have your developer build the current app with Xcode 27 on a test branch. You don't have to ship it yet. You're finding out what breaks while there's no pressure. A clean build is good news; a list of errors is a plan.

List the third-party libraries. For each, note the version you use and whether a current version supports Xcode 27. If one has been abandoned, decide now whether to replace it.

Check who holds the keys. Confirm the Apple developer account is owned by your business, that two people can sign in, and that the certificates and build setup are documented somewhere you control.

Ship one routine update before April. Small fixes, a copy change, an updated library, built with Xcode 27 and released normally. Then April is a date that already happened to you, not one waiting for your next emergency.

Look at who's on old devices. Your app analytics can usually show which iOS versions your users run. Apple's pages don't list which iPhone and iPad models are affected. If a real share of your customers, or your own staff on shared iPads, run something older than iOS 15, they keep the version they have but won't get updates you ship from April. For a staff app, the fix may be a device policy, not code.

Put it in the budget. If an agency or freelancer maintains the app, ask them now for a short written answer: has the project been built with Xcode 27, what broke, and what will it cost to fix? Getting that answer in November means the work fits into a normal month. Getting it in May means paying for urgency. If they can't answer, that tells you something too.

If the app has no one looking after it

The apps most exposed to this deadline are the ones that quietly work. If yours was built a while ago and nobody is responsible for it today, this is a good moment to change that: an occasional check-in, tools kept current, a named person who can upload a fix in a day. It doesn't need to be expensive. A few hours each quarter to build the app with current tools, update libraries and confirm the accounts still work is usually enough to keep an April like this one from turning into a crisis.

That's the kind of ongoing care our mobile applications team provides, alongside new builds. If you're not sure where your app stands, talk to us and we'll help you find out before April does.

Related work: Sutton Place.