If you ship an iPhone or iPad app, Apple has now written down the next hard deadline. Starting in April 2027, Apple says iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS and iPadOS 27 SDK or later, and must target iOS 15 or later. Apple has not published an exact day yet, so treat "April" as the planning date and work back from it. The part that surprises teams is not the SDK number. It is a second change that arrives with that SDK and can stop an older app from launching at all.
Three floors, and which ones are already in force
It helps to separate the rules that already apply from the one that is coming. According to Apple's upcoming requirements page , since April 28, 2026 uploads must be built with Xcode 26 or later using the 26-series SDKs. Since September 9, 2026, iOS and iPadOS uploads must also target iOS 13 or later. Both are live today, so if your pipeline is still passing, you have already cleared them. The April 2027 step is the next one: the 27 SDK, which means Xcode 27, plus a deployment target of iOS 15. If any target in your project, including app extensions and widgets, still says iOS 13 or 14, that is the line item to fix first.
The change that can break launch: UIScene
The SDK floor is a calendar problem. The scene lifecycle is an engineering problem. Apple's scene-based life cycle guide says adoption is required: beginning in iOS 27, apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch. The requirement follows the SDK you build with, so it lands the day you move your CI to Xcode 27, not the day a customer updates their phone. Apple gives two tests for whether you are affected. Either the UIApplicationSceneManifest key is missing from your Info.plist, or your app delegate does not implement application(_:configurationForConnecting:options:) . Apple also notes that UIKit has logged a warning about this since iOS 18.4, so a console message saying your process does not adopt the UIScene lifecycle is your early signal.
# Quick check, run from each app target's folder
grep -rn "UIApplicationSceneManifest" --include=Info.plist .
grep -rn "configurationForConnecting" --include=*.swift --include=*.m .
grep -rn "IPHONEOS_DEPLOYMENT_TARGET" --include=*.pbxproj --include=*.xcconfig .What it means for React Native, Expo, and Flutter teams
React Native and Expo. The iOS 15 floor is less of a jump than it looks. A merged Expo pull request records that React Native 0.76 required iOS 15.1 and Expo followed, so a current project is probably already above Apple's new minimum. The real risk is native code your team added by hand: a custom AppDelegate, a third-party SDK that creates its own window, or a deep-link handler that assumes app-level lifecycle callbacks. We covered the Expo side of the upgrade path in our Expo SDK 58 upgrade plan . Flutter. Flutter's UIScene migration guide says UIScene support has been the default since Flutter 3.41, and that an unmodified AppDelegate is migrated automatically when you build. If your AppDelegate is customized, or you are on an older Flutter, you migrate by hand, and the same guide warns that a Flutter app built with Xcode 27 without UIScene fails to launch. Flutter's supported platforms page currently lists iOS 15 to 27 as supported. Native Swift and Objective-C. Apps created from Xcode templates in the last several years usually already have a scene manifest. The older ones, especially apps that started before iOS 13, are the ones to check.
Who decides to drop iOS 13 and 14
Raising the deployment target to iOS 15 is the one part of this that is a product decision rather than a toolchain task. Apple's requirement means new uploads cannot support anything below it, so the question to put to your team is simple: how many of your active users are still on iOS 13 or 14, and are any of them in a contract that names an OS version? B2B apps are where this bites. A field-service customer with a locked-down fleet of older iPads may be exactly the account that cannot upgrade. Pull the iOS version breakdown from your analytics, check enterprise contracts and MDM policies for named versions, and tell the affected customers early. If you are choosing between native and web for an internal tool, our piece on native app versus responsive web is the right context for the trade-off.
A plan you can start this month
November. Install Xcode 27 on one build machine and one developer laptop. Build a branch, launch it on a device, and list every failure. Run the three grep checks above and write down which targets have an old deployment target. December and January. Migrate to the scene lifecycle, raise the deployment target to iOS 15, and ship that as a normal release while Xcode 26 still works for uploads. That ordering matters: you want the migration live and soaked with real users before the SDK change arrives. February and March. Move CI to Xcode 27 and fix what the new SDK flags. Keep a short written note of what changed, because customer security and procurement reviews often ask which OS versions you support and why.
Do not forget the other platforms
Apple's submit page lists the same April 2027 pattern for the other platforms: tvOS, visionOS, and watchOS apps must be built with their 27 SDKs. If your company ships a companion watch app or a visionOS build, it needs the same calendar entry. Android teams have a parallel date to track, which we wrote up in the AppFunctions and Play policy piece , so one April 2027 planning meeting can cover both stores.
Founder takeaway
The April 2027 deadline is five months away, which is enough time only if you start before the holidays. Treat it as three tasks: raise the deployment target to iOS 15 with your customers informed, migrate to the scene lifecycle on the current SDK, and move CI to Xcode 27 last. Check Apple's pages again in the new year, since the exact date is still to be announced. Want a second pair of eyes on your iOS release pipeline before April? Talk to the CodeFlamme team , or read how we think about React Native versus Flutter if a rebuild is on the table.
