Expo SDK 58 beta: iOS 27 scenes and iPhone Duo

Expo published the SDK 58 beta on 15 September 2026, and five days later Apple shipped the Xcode 27.1 beta with the iPhone Duo simulator. If you run an Expo app, that combination raises exactly one question: what do I do this week?

The short answer is probably not what the release note implies. SDK 58 beta does fix the iOS 27 launch failure — but SDK 57 can build with Xcode 27 today, behind a single flag that is documented almost nowhere, and for most shipping apps that is the cheaper and safer route. This post is about which of those two you should pick, and about the thing neither of them gives you yet.

What SDK 58 beta actually is

As a version string rather than a headline: [email protected], published on 16 September and carried by the next dist-tag. You install it with

npx expo install expo@next --fix

or start clean with npx create-expo-app@latest --template default@next.

Three facts about it matter more than the feature list:

• It is built on React Native 0.88, which is still a release candidate. 0.88.0-rc.1 landed on 15 September. React Native’s own schedule puts 0.88 stable on 12 October 2026, and Expo has said stable SDK 58 follows shortly after React Native 0.88 ships.
• The beta is expected to run three to four weeks. So roughly mid-October, which is the same fortnight as iPhone Duo going on sale on 23 October.
• You are not being rushed. Expo’s own framing is that you have time to upgrade before the store version drops SDK 57 support.

What it fixes: scenes by default

The problem SDK 58 solves is not subtle. Apple’s iOS 27 release notes:

Apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch.

An unmodified Expo app built with Xcode 27 stops dead:

Application failed to launch: UIScene life cycle is required for apps built
with this SDK. See Technote TN3187 for more information on migration.

In SDK 58, prebuild generates a SceneDelegate.swift and adds a UIApplicationSceneManifest entry to Info.plist, so a stock project launches. If you have customised AppDelegate.swift — and most production apps have, to register method channels, push notifications or a native SDK — you follow the migration guide by hand. That is the same caveat Flutter carries, and it is where these migrations actually go wrong.

You probably should not upgrade for this

Here is the part that is missing from most coverage of the launch failure.

The SDK 57 backport everyone was waiting for was closed unmerged on 15 September. Rewriting the SDK 57 template would have deleted the AppDelegate.swift lines that config plugins across the ecosystem anchor their code modifications to, which would have broken a long tail of projects to fix one thing. So Expo did it the other way round: the scene life cycle runtime was merged to the sdk-57 branch, the templates were left alone, and adopting it became opt-in.

The opt-in is a property on expo-build-properties, and its own published documentation is the clearest statement of what it does:

Adopt the UIKit scene lifecycle in an Expo SDK 57 iOS project, as required by the iOS 27 SDK (Xcode 27). When true, the AppDelegate exposes its ExpoReactNativeFactory, React Native startup moves to Expo’s scene delegate, and the scene manifest is added to Info.plist.

In your app config:

{
  "expo": {
    "plugins": [
      ["expo-build-properties", { "ios": { "enableSceneSupport": true } }]
    ]
  }
}

Two conditions, both stated in that same documentation, and both easy to trip over:

1. You need expo 57.0.23 or newer. That is the release the runtime shipped in. The newest SDK 57 release is 57.0.24, so a plain npx expo install expo@latest clears the bar — but a project pinned to 57.0.19 will set the flag and still fail to launch, which is a confusing afternoon.
2. Only the standard SDK 57 Swift AppDelegate template is supported. If yours is heavily customised, you are migrating by hand whichever SDK you are on.

One thing to skip: you may be pointed at a separate @config-plugins/expo-uiscene-lifecycle plugin. It was merged on 15 September, but it is not published to npm — the package name returns a 404 on the registry as of 20 September 2026. Use the expo-build-properties flag.

So the recommendation, for a team with an app in the stores: stay on SDK 57, set the flag, and be building with Xcode 27 this afternoon. Take the 58 beta on a branch, for the reasons in the next section — not to fix your launch failure.

If you do take the beta

SDK 58 brings a great deal more than scenes, and an upgrade decision should be made against the whole list rather than the one fix. The parts most likely to cost you time:

• React Native 0.88 is a release candidate. Every native dependency you have is being tested against it by someone, but not necessarily by its maintainer.
• Strict TypeScript API enforcement. Expect type errors in code that reached into React Native internals.
• File.write() is now async. File.writeSync() restores the old behaviour.
• Android R8 minification is on by default, which is a release-build behaviour change, not an iOS one — so it will surprise you on the wrong platform.
• expo-router’s navigation core was refactored. Custom navigators are the exposed surface.
• libSQL support was removed from expo-sqlite, and the useLibSQL config property is deprecated.
• Deprecations to schedule rather than fix now: File.md5() in favour of File.digest(), NativeArrayBuffer in favour of ArrayBuffer, the AppMetrics export in favour of Observe, and backgroundOverlay on iOS in favour of background.

The genuinely new capabilities are worth a look on that branch: expo-app-intents exposes App Intents, so Siri, Shortcuts, Spotlight and Apple Intelligence can reach into your app, and Expo Modules 2.0 replaces the module DSL with annotated Swift and Kotlin classes. Neither is a reason to ship a beta to customers.

One operational note: EAS Build images carrying Xcode 27 and the SDK 58 toolchain were described as coming soon, with latest still on Xcode 26.6. Check what your build profile resolves to before you conclude that your local fix works in CI.

What SDK 58 beta does not give you: iPhone Duo

This is the part the version number invites you to assume, and it is not true.

Expo’s own wording in the beta announcement is careful:

We’ll also ship improvements during the beta to ensure deep integration with iPhone Duo from day one, as soon as the iPhone Duo SDK is available to developers.

That SDK arrived on 18 September, inside the Xcode 27.1 beta — see what the Xcode 27.1 beta contains. So the door is now open, but nothing has shipped through it.

What exists is a community draft pull request, opened 18 September, proposing an expo-display-features module that would expose reserved regions and hinge state:

// Proposed in a draft PR — not published, not on a release schedule.
getDisplayFeaturesAsync();
getHingeAsync();
addDisplayFeaturesChangeListener(listener);
useDisplayFeatures();
useHinge();

It is gated behind an optional EXPO_IPHONE_DUO_SDK compile flag, because Expo’s continuous integration is capped at Xcode 26.6 and cannot compile against the new APIs at all. Read that as the honest status: a draft, written against a beta, that CI cannot build.

Your app will still run on iPhone Duo without any of this. It resizes, and Apple’s guidance is that an app built from standard components and designed to resize adapts to the poses with little adjustment. What you cannot do from JavaScript is know that there is a fold, or where it is.

What you can do about the fold now

Reserved regions and the hinge are UIKit APIs. Until Expo ships a module, the bridge is one you own — which is a day or two of native work, not a project.

The two surfaces worth exposing first, in order of how much design they unlock:

1. Reserved regions, so you can stop drawing controls where the hardware will cover them. This is the one that prevents visible bugs.
2. Hinge state, via UIHingeInteraction, so a layout can respond to the device being half-open rather than only to its size.

We have sketched that native module — the event emitter, the hook and the failure modes — in the React Native and Expo iPhone Duo playbook, along with the four layout traps that break a React Native app on the inner display before any of this comes up. Those traps are independent of your SDK version, and fixing them is the work that pays off whether or not Expo ships a fold API.

A plan, in order

1. Today: get off the launch failure. SDK 57, expo at 57.0.23 or newer, ios.enableSceneSupport set. Build with Xcode 27 and confirm the app launches.
2. This week: check your AppDelegate. If it is customised, plan the scene migration by hand. This is the item that turns into a week if you leave it.
3. This week: install the Xcode 27.1 beta alongside Xcode 27 and boot the iPhone Duo simulator. Fix the layout traps you find; they are yours regardless of SDK.
4. On a branch: try SDK 58 beta. Verify your native dependencies against React Native 0.88 RC, and check what Xcode your EAS build profile actually gets.
5. Mid-October: reassess. React Native 0.88 stable is scheduled for 12 October and SDK 58 stable follows it. That is when the upgrade stops being a beta decision.
6. Do not wait for an Expo fold API to start. Nothing about it is scheduled, and the native bridge is small.

If you would rather have an engineer look at it, send us your App Store link and the SDK you are on. We will tell you what breaks on iPhone Duo, whether your scene migration is a flag or a week, and what it would cost — the owner’s guide to iPhone Duo and iOS 27 is the plain-language version of the whole picture.