The Expo UIScene lifecycle switch is the iOS change most React Native teams will meet by accident this autumn. Apple says that once apps build against the SDK after iOS 26, an app still on the old AppDelegate lifecycle will not launch at all. Expo SDK 58 moves every app onto scenes to get ahead of that, and the patch it published on October 5, 2026 shows where the move still leaks: code that assumed the app delegate owns the window.
What changed in Expo SDK 58 on iOS
Expo SDK 58 starts React Native from a scene delegate instead of the app delegate, so the window, deep links and life cycle events now arrive through UIWindowScene. Apple's technote TN3187 sets the deadline: from the next major release after iOS 26, building with the latest SDK requires the scene life cycle, and only adopting it is mandatory, not supporting several windows.
React Native core has not migrated yet, so Expo shipped its own ExpoAppSceneDelegate base class, first in the 58.0.0 preview of September 10, 2026, on top of React Native 0.88 release candidates. The expo package changelog reads like a list of everything that broke on the way. Cold-start deep links returned null from Linking.getInitialURL(). URLs delivered to a running app emitted no JavaScript event. Handoff and quick action events stopped reaching app delegate subscribers. Each got a fix before or at 58.0.0. Version 58.0.4 adds the latest one: an overridable initialProperties on the scene delegate, because the old RCTAppDelegate.initialProps hook had no equivalent once startup moved into scene(_:willConnectTo:).
AppDelegate vs UIScene: what moves where
Under the scene life cycle the app delegate keeps process-level work, and everything tied to a window moves to the scene delegate. Push token registration, background fetch and SDK initialisation stay in the app delegate. Window creation, the React root view, URL opens, user activities and foreground or background transitions now belong to the scene.
That split sounds tidy. The problem is that a decade of native iOS code, and most React Native libraries with a native half, was written when the app delegate was the single entry point. Code that reads the window from the application delegate still compiles. It just finds nothing there. In the best case the result is a missing value. In the worst case it is a crash at launch, because window is an optional property and a scene-style app delegate often does not declare it.
The comparison we give clients is simple. With AppDelegate, one object answers "what is on screen" and "what is the process doing". With UIScene, two objects answer those questions, and any library that asks the wrong one fails quietly or loudly depending on how it was written.
Where React Native apps break first
Push notifications, deep links and anything that seeds the root view with launch properties break first, because those are the paths that touched the window from the app delegate. Commerce apps lean on all three: a promotional push that opens a product, a shared link that lands on a cart, a silent notification that refreshes stock.
The clearest public example sits in React Native Firebase messaging. An open pull request from October 2, 2026 guards two reads of the app delegate window that crash scene-based apps with an unrecognised selector at launch. The bug was first reported in December 2025. The fix avoids the crash, but when no window is found it skips writing the isHeadless flag into the root view's properties. That flag is how JavaScript knows a background push started the app without a visible screen. The Expo 58.0.4 initialProperties override exists partly to restore it.
So the realistic state today: an app on SDK 58 with Firebase messaging can launch, but whether a background notification wakes a full UI or a headless task depends on library versions and on whether someone overrode the new hook. That is the kind of regression nobody sees on a simulator and every user sees as battery drain or a phantom screen.
What we would change on a React Native app this quarter
Move to Expo SDK 58.0.4 or later in a branch now, then audit every native dependency that touches the window before your first build with the iOS 27 SDK, the one TN3187's rule applies to. On the mobile apps we build, the order would be this.
- Grep the iOS sources of every native dependency, including
node_modules, for reads of the delegate window and forinitialProps. Each hit is a library to upgrade, patch or replace. - Test the four launch paths on a real device, not a simulator: cold start from the icon, cold start from a universal link, cold start from a push tap, and a silent push with the app killed. Log what JavaScript receives in each case.
- If you use Firebase messaging, decide where
isHeadlesscomes from. OverrideinitialPropertiesin your scene delegate subclass and verify the flag reaches the root component on a background launch. - Keep custom native code out of
AppDelegateunless it is truly process-wide. Anything that renders, presents or reads the screen belongs to the scene.
For bare React Native projects outside Expo, the work is larger, because there is no ready-made scene delegate until React Native core migrates. Budget for writing one, or for moving to Expo's, which is the path we would recommend for most commerce apps. The React Native 0.87 release already made typed upgrades cheaper; this is the native half of the same upgrade discipline.
The quiet risk is timing. Teams that ship a store app twice a year tend to bump the Xcode version and SDK in the same release that adds a seasonal campaign. If that release is also the first one on the new SDK, the push that announces the campaign is exactly the path most likely to misbehave.