What iOS 27 changes for shipping
The scene lifecycle became mandatory, Xcode 27 dropped Intel Macs, and CocoaPods goes read-only in December. What each one means for getting a build to the App Store this autumn.
· 7 min read
Three changes landed this autumn that affect whether your build ships, not how it looks. None of them are features. All of them will eventually stop a release.
1. The scene lifecycle is mandatory
Apps built against the iOS 27 SDK must adopt the UIScene lifecycle. An app that has not does not degrade — it does not launch:
Application failed to launch: UIScene life cycle is required for apps built with this SDK
A SwiftUI app using the App protocol is already scene-based and has nothing to do. The apps that break are UIKit ones with an AppDelegate that owns the window — including plenty of code an AI agent will happily write, because the pattern is everywhere in the training data and has been for a decade.
The migration is a UIApplicationSceneManifest entry in Info.plist and moving window setup into a scene delegate. Apple's technote TN3187 is the reference. Cross-platform frameworks hit this too — Capacitor shipped a migration for it, and Expo filed bugs against the Xcode 27 betas for the same reason.
Who is affected today: only builds compiled with the iOS 27 SDK, which means Xcode 27. An app already on the store, built with Xcode 26, keeps running on iOS 27 devices untouched. This is a build-time cliff, not a device-side one — which is why it catches teams the first time they update Xcode rather than when users update their phones.
2. Xcode 27 is Apple silicon only
Intel Macs cannot run it. If your build machine is an older Mac mini or an Intel MacBook that has been quietly doing releases for years, its retirement date is now set by Apple rather than by you.
The same applies to CI: an image pinned to an older macOS on Intel hardware stops being an option, not gradually but at whatever point you need the new SDK. Worth knowing before it is urgent — see where to build when you have no Mac.
3. CocoaPods goes read-only on 2 December
CocoaPods Trunk stops accepting new podspecs permanently on 2 December 2026, with a dry run from 1–7 November. To be precise, because this gets overstated: existing builds keep resolving, the CDN stays up, nothing you have shipped breaks. What ends is publication — so your dependencies stop receiving updates through that channel and the ecosystem moves to Swift Package Manager with or without you.
If your project still uses a Podfile, the migration is not urgent this week and will be urgent by spring. Doing it while nothing else is changing is much cheaper than doing it alongside an SDK bump.
What has not changed
Apple's submission floor is still the iOS 26 SDK, in force since 28 April 2026. You are not yet required to build with Xcode 27, and a build made with Xcode 26 uploads fine today. Apple raises that floor roughly annually, so treat the scene migration as work for this quarter, not this week — but do not treat it as optional.
The order to do this in
- ·Check whether your app is UIKit-with-AppDelegate or SwiftUI. If SwiftUI, you are likely already done.
- ·Migrate to the scene lifecycle on a branch and launch on an iOS 27 simulator — it either starts or it does not, which is a fast signal.
- ·Re-test cold launch from a push notification and from a universal link. Those are the paths that silently stop working.
- ·Confirm your build machine or CI image runs on Apple silicon.
- ·Schedule the CocoaPods to SPM move before December.
If your builds run on NoMac, points two and three are already handled: builds run on Apple-silicon cloud Macs with a current toolchain, and dependency resolution happens in the build VM rather than on a machine you maintain. Point one is your app's source code, and no build service can migrate that for you — though the agent that wrote the app can.
For the paperwork that stops releases in the same season, see Apple's three paperwork blockers.