April is a build deadline.
From April 2027, every app uploaded to App Store Connect for iPhone, iPad, Apple TV, Vision Pro or Apple Watch has to be built with the 27 generation SDK. Nothing live gets pulled. But the next fix to any app nobody has opened in two years now starts with a toolchain upgrade, and that is a much cheaper job in October than on the day something breaks.
On 9 September, the same day Xcode 27 reached release candidate, Apple opened App Store submissions for its new operating systems and set a date at the bottom of the post. Starting April 2027, all apps uploaded to App Store Connect must be built with the 27 generation SDK or later. That covers iOS and iPadOS, tvOS, visionOS and watchOS. macOS was left off the list.
The Mac got its own news instead. macOS 27 shipped on 14 September and installs only on Apple silicon Macs. Apple's developer note says it is the final release to support Rosetta, so after this cycle an Intel-only app stops running on a current Mac, with an exception for older, unmaintained games. Developers still shipping universal builds were told to set the architecture to arm64 only, rebuild and resubmit.
Nothing gets removed. Nothing gets updated either.
The requirement applies to uploads. An app that is live today stays live in May. What changes is the cost of touching it. A copy change, a crashed screen on a new phone, a payment provider that retires an endpoint, any of those now needs a build out of Xcode 27 before it can ship.
For an app that is maintained every month, that is a normal week. For an app that was finished, signed off and left alone, it is a different job. The project has to open in a new Xcode. Its dependencies have to resolve against a new SDK. Deprecated calls have to go. Signing has to work on a machine that is not the one it was last built on. And since this month, every new version also has to answer Apple's age rating question about social media capabilities before it can be submitted at all.
The expensive version is the urgent one.
None of that is difficult on a quiet Tuesday. All of it is painful when it stands between a live bug and a fix. The deadline does not create the work. It fixes the date after which the work arrives unannounced, attached to something that was supposed to take an hour.
- 01Prove you can build it. From a clean machine, can someone produce a signed build of the app today. If the answer is no, that is the ticket, ahead of any feature.
- 02Rebuild with nothing to ship. Put each app through Xcode 27 and TestFlight this autumn, even with no changes. Find what breaks while nothing is on fire.
- 03Write the toolchain down. Xcode version, SDK, dependency lockfile and signing setup, recorded in the repo rather than in someone's memory.
- 04Answer the social media question now. Leaderboards, visitor walls, anything that spreads user content to other users needs a considered answer, not one typed in during a release.
- 05Audit the Macs in the building. Installations and kiosks running on Intel Mac minis, or relying on an Intel-only app, have a known end date. Plan the swap rather than discover it.
Should clients care.
If the app is finished and nobody will want anything from it next year, not much. If there is any chance of a change, a new feature, a rebrand, or a fix nobody has spotted yet, then the cheapest moment to find out what the rebuild costs is between now and April, as a planned piece of work.
That is what we are doing across the apps we look after. A build check first, a rebuild on the new toolchain second, and a short note to each client saying which of the two turned anything up.