Expo SDK 58 Upgrade Guide: React Native 0.88 and iOS 27

The short version

Expo SDK 58 at a glance

Verify the exact pins for your own project rather than trusting a table in a blog post — including this one. npx expo install --check compares every dependency against the version the installed SDK expects, and the beta's pins move during the beta period.

What actually changed in SDK 58

React Native 0.88, skipping 0.87

SDK 57 was on React Native 0.86. SDK 58 goes straight to 0.88, so you inherit 0.87 and 0.88 in a single upgrade. React Native 0.87 was the cleanup release: it removed a long list of deprecated APIs and made the Strict TypeScript API the default. That is where most of your compile errors will come from.

0.88 itself adds the opt-in npx react-native spm Swift Package Manager pipeline (CocoaPods remains the default and supported path), fontVariationSettings on Text, native ArrayBuffer representations in TurboModules, and WebSocket inspection in React Native DevTools.

iOS 27 and the scene-based life cycle

The iOS 27 SDK requires the UIKit scene life cycle. An app built with Xcode 27 that still uses the application-based life cycle does not launch correctly on iOS 27, so Expo moved. npx expo prebuild now generates a SceneDelegate.swift and a UIApplicationSceneManifest entry in Info.plist, and the UIWindow is created by the scene delegate rather than in didFinishLaunchingWithOptions.

R8 on by default for Android release builds

The Android app template now sets android.enableMinifyInReleaseBuilds=true in gradle.properties. R8 shrinks, optimizes, and obfuscates your Java and Kotlin code with the proguard-android-optimize.txt preset. Smaller app, faster startup, and a new class of release-only crash if a library relies on reflection.

Expo Router's navigation core was rewritten

Navigation state and route keys are deterministic now, dispatch is deferred until after commit, and most of the forked React Navigation API surface is gone. Data loaders, server-side rendering, middleware, native tabs, and toolbars all graduated to stable. Apps that only use Stack, Link, and useRouter need a few small changes; custom navigators and anything importing from expo-router/react-navigation need a proper review.

The quieter wins

• Faster Android builds. expo-modules-core now ships precompiled .so files for all four ABIs. Expo measured a clean debug build dropping from roughly 80 seconds to 39 on an M3 Pro, and the saving is bigger on CI runners with fewer cores.
• Fingerprint defaults to the balanced preset. Bumping version in app.json or touching files inside node_modules no longer changes your fingerprint, so you stop paying for unnecessary native rebuilds.
• Faster Expo modules on iOS. Simple-value calls are cheaper, long strings move up to 3.8× faster, and promises cost less to create and resolve. Nothing to adopt — every Expo module gets it.
• Expo Modules 2.0 beta on both platforms: write a normal Swift or Kotlin class with annotations instead of the DSL.
• Experimental Rust bundling. "Noxcturnal" is an oxc-based transformer behind experiments.noxcturnalTransformWorker. Expo measured around 2× faster cold bundling. It only activates when you have no custom transform worker and no Babel plugins or presets, which rules out most real projects today.
• New APIs worth knowing: expo-app-intents for Siri and Apple Intelligence (alpha), Android home screen widgets in expo-widgets, CameraView.scanDocumentAsync, File.digest(), variable font support in expo-font, and lockscreen audio controls with playlists.

How to upgrade SDK 57 to SDK 58

1. Start from a clean branch

You will want to read this diff, and you will probably want to abandon it once before you keep it:

2. Check Node.js

SDK 58 requires Node 22.13 or newer on the 22 line, 24.3 or newer on the 24 line, or Node 26 and later. Odd-numbered releases like 23 and 25 are not supported at all:

Check your CI image and your EAS Build profiles too, not just your laptop. A machine on Node 22.11 will fail in a way that looks like an Expo bug.

3. Install the SDK 58 beta

While SDK 58 is in beta, you install from the next tag rather than a version range:

--fix is doing the real work: it pulls React, React Native, every Expo module, and the third-party packages Expo tracks up to the versions SDK 58 expects. Once SDK 58 ships stable, this becomes the familiar npx expo install expo@^58.0.0 --fix.

4. Run Expo Doctor

Fix what these report before you build anything. A native build failure on top of an unresolved dependency mismatch is two problems pretending to be one.

5. Migrate TypeScript to the Strict API

This is the change most likely to produce a wall of red. React Native 0.87 made the Strict TypeScript API the default, so deep imports are now type errors and some types changed shape — most visibly refs, which use instance types such as ViewInstance and TextInputInstance:

If that's a bigger job than you want inside an SDK upgrade — and in a large app it usually is — you can defer it. Add the legacy condition to tsconfig.json, keeping "react-native", which expo/tsconfig.base already sets:

6. Regenerate your native projects

If you use Continuous Native Generation and don't commit ios and android, this is one command:

That regenerates both platforms, which is what produces the new SceneDelegate.swift, the UIApplicationSceneManifest entry in Info.plist, and the android.enableMinifyInReleaseBuilds=true line in gradle.properties. If you maintain the ios directory by hand, see the scene life cycle section below — you have three files to change. For bare React Native apps using Expo modules, npx install-expo-modules@latest performs the migration for you.

7. Work through the Expo Router changes

Four removals will hit ordinary apps. First, initialRouteName is gone; the replacement is an unstable_settings export from that stack's layout:

anchor is the back destination when someone deep links into the stack — it is not how you choose the app's first screen. The launch URL decides that, and / resolves to your index.tsx.

Second, layout Screen components no longer accept redirect or initialParams. Render a Redirect from the route file, and read defaults where you read the params:

Third, tabs and drawers now show only the screens declared in the layout. If your tab bar quietly lost entries after upgrading, this is why:

Fourth, freezeOnBlur has no effect. Remove it and use activityEnabled, which preserves screen state while cleaning up effects:

Two more to check. Imperative navigation with navigation.navigate("(tabs)", { screen: "feed" }) no longer builds nested state — screen, params, and initial are ordinary user params now, so navigate to a complete href with router.push({ pathname: "/(tabs)/feed/[id]", params: { id: "42" } }). And expo-symbols and @expo/ui became optional peer dependencies, so if you use Android md icons in native tabs or Stack.Toolbar, install them explicitly:

Protected routes mostly survive untouched. They stay registered in their navigator, and a route whose guard fails renders a redirect instead of being removed from the tree — so the patterns in Expo Router Firebase Auth: protected routes, tabs, and login flows still hold. Set redirectTo on Protected only when you want to control where a failed guard sends people.

8. Rebuild, then actually test

Then read the diff properly — git diff across package.json, app.json, and the native directories if you commit them. Two upgrades in one branch is how you end up unable to tell which one broke the build.

React Native API removals you will actually hit

Crossing 0.87 and 0.88 together means the removal list is longer than usual. These are the ones that show up in real codebases:

• InteractionManager is removed. Use requestIdleCallback. Most uses in app code are a runAfterInteractions wrapper around navigation-adjacent work, and plenty of them can just go.
• The Touchable root export is removed. If you're still on it, you're several years past Pressable.
• The NativeMethods types are removed — part of the same Strict API change as the ref instance types.
• Modal's animated prop is removed. Use animationType.
• StatusBar's deprecated backgroundColor, translucent, and networkActivityIndicatorVisible props are removed. This one catches people, because Android status bar colouring is exactly the sort of thing written once in 2021 and never touched since.
• ImageBackground is deprecated in favour of a View with an absolutely positioned Image. Deprecated, not removed — but it's on the clock.

A few Expo-side behaviour changes worth grepping for as well: @expo/ui's <Host> top-aligns on iOS instead of centering, HStack and VStack use system default spacing unless you pass spacing={0}, RNHostView dropped style on Android in favour of modifiers, and expo-localization no longer force-enables RTL from the device locale on iOS — layout direction follows I18nManager now. If you built screens with Expo UI, re-screenshot them.

iOS 27 and the scene life cycle

Under the old application-based life cycle, AppDelegate created the UIWindow and received every URL, user activity, and foreground/background callback. Under the scene life cycle, UIKit creates a UIWindowScene and calls a scene delegate instead, and it no longer calls application(_:open:options:), application(_:continue:restorationHandler:), the four applicationDid/Will foreground and background methods, or the quick action handler.

Expo provides the infrastructure: ExpoAppSceneDelegate creates the window and starts React Native, then routes URL, user activity, Handoff, life cycle, and quick action events back through ExpoAppDelegate, which forwards them to your overrides and to ExpoAppDelegateSubscriber implementations. Delivery stays single, so a legacy override that calls RCTLinkingManager itself won't produce a duplicate url event.

You don't need to do anything if you use CNG and don't commit ios, or if your native code lives in config plugins using ExpoAppDelegateSubscriber or in Expo modules. You do need to act if you maintain ios by hand, have a bare React Native app, or override UIApplicationDelegate methods directly.

For a hand-managed project, there are three changes. Add SceneDelegate.swift next to AppDelegate.swift, in the app target:

Declare the scene manifest in Info.plist, keeping the $(PRODUCT_MODULE_NAME) prefix so UISceneDelegateClassName resolves:

And stop creating the window in AppDelegate. The fastest way to get this right is to run npx expo prebuild --platform ios in a scratch copy of the project and diff the generated ios directory against yours.

The React Native Firebase break

This one is worth its own section, because it is silent, it is iOS-only, and it produces an app that launches fine and then fails at the first Firebase call.

The @react-native-firebase/app config plugin patches AppDelegate.swift to insert FirebaseApp.configure(). It finds its insertion point by matching on self.moduleName = "..." or factory.startReactNative(. Neither exists in the SDK 58 AppDelegate, because React Native is started from the scene delegate now. So prebuild prints this and moves on:

import FirebaseCore may still be added, but FirebaseApp.configure() is not, so native Firebase never gets a default app. It is tracked as issue #9331, open as of 21 September 2026. Until it's fixed, a local config plugin that runs after the Firebase one will do it:

Register it after the Firebase plugin, because plugins run in array order:

Both throws are deliberate. A plugin that silently does nothing is exactly the failure mode you're working around — you want prebuild to stop if the AppDelegate shape changes again. Delete the whole thing once the upstream fix ships; the early return means it's harmless in the meantime, but dead config plugins have a way of becoming permanent.

R8 is on now, and it will find your reflection

Release builds minify by default in SDK 58. The failure mode is specific and nasty: debug builds work, release builds crash or silently misbehave, and the stack trace is obfuscated. Libraries that rely on reflection — JSON serializers mapping to model classes, anything resolving classes by name — need keep rules.

Add them through expo-build-properties rather than editing proguard-rules.pro by hand, so they survive the next prebuild:

If a release build breaks and you need to ship before you can diagnose it, turn minification off to confirm R8 is the cause, then turn it back on and fix it properly:

The point of the upgrade is the smaller, faster app you get with R8 on. Leaving it off permanently gives back real startup time. Test a release build on a device before you conclude the upgrade went fine — a development build proves nothing here.

The NODE_ENV change that will confuse your CI

Every Expo CLI command now sets NODE_ENV to development or production before loading .env files and your app config, so a dynamic app.config.js and the .env cascade always agree about which mode they're in. Previously, commands inherited NODE_ENV if one was set, and expo config never set one at all.

So NODE_ENV=test npx expo start used to load .env.test. It now ignores the inherited value and loads .env.development. If a CI job or a shell profile sets NODE_ENV, the environment your app builds against just changed underneath you. Jest still sets NODE_ENV=test in tests, and @expo/env still resolves .env.test.local, .env.test, and .env there, so test runs are unaffected.

Grep your CI config and your package.json scripts for NODE_ENV before you trust a build. If you keep Firebase config in environment variables, the EAS Build environment variables guide covers which values belong in .env files and which belong in EAS environments — this change makes the distinction matter more, not less.

Should you upgrade now?

Three honest answers, depending on who you are:

• You need iOS 27 support now. Upgrade. Expo explicitly says you can ship on the beta for this reason, and it's the only supported way to get the scene life cycle without hand-patching SDK 57. Build locally with Xcode 27 until the EAS image lands.
• You have a live app and no iOS 27 deadline. Do the upgrade on a branch this week, find your problems, then sit on it until stable. The beta runs three to four weeks from 15 September and pins move during it. The value of going early is knowing what's ahead of you, not shipping it.
• You're still on SDK 55 or 56. Go to 57 first. SDK 58 is a big enough release on its own without stacking another SDK's breaking changes underneath it — start with the SDK 57 upgrade guide and come back.

One thing not to do: don't run this upgrade in the same branch as a feature. When something breaks in four weeks you want git log to give you one commit to interrogate.

Does Expo Go support SDK 58?

During the beta, yes — but not from the app stores. Expo Go for SDK 58 is available through Expo CLI for Android devices, Android emulators, and iOS simulators, and through eas go for physical iOS devices. The App Store and Google Play builds update to SDK 58 shortly after the stable release, which is also when they stop supporting SDK 57.

That deadline is the practical reason not to leave this upgrade too long if you rely on Expo Go for development. For production apps, development builds are the right answer regardless: they support your actual native dependencies, and EAS keeps backwards compatibility for older SDKs far longer than Expo Go does.

Production migration checklist

• Upgraded on a dedicated branch with no unrelated changes
• Node 22.13+, 24.3+, or 26+ on every machine, including CI and EAS profiles
• npx expo-doctor@latest and npx expo install --check both clean
• TypeScript either migrated to the Strict API or explicitly deferred, with a ticket to do it this cycle
• Gesture-driven screens retested after the Gesture Handler 2 to 3 jump
• Native projects regenerated with npx expo prebuild --clean
• Verified FirebaseApp.configure() is present in the generated AppDelegate.swift, if you use native Firebase
• Every config plugin that patches AppDelegate re-verified against the scene-based file
• Deep links, universal links, Handoff, and quick actions tested on iOS under the new life cycle
• Tested an Android release build on a device with R8 enabled
• Expo Router: initialRouteName, redirect, initialParams, and freezeOnBlur all removed
• Every tab and drawer screen explicitly declared in its layout
• Checked NODE_ENV is not set by CI or a shell profile in a way that changes which .env loads
• Orientation and resizable-window behaviour checked on iOS 27
• EAS Update runtime versions bumped so SDK 58 JavaScript can't reach SDK 57 builds
• Staged rollout with crash and performance monitoring before a full release

Expo SDK 58 FAQ

Which React Native version does Expo SDK 58 use?

React Native 0.88. The beta ships the release candidate, currently 0.88.0-rc.1, because React Native 0.88 has not shipped stable. SDK 57 used 0.86, so SDK 58 picks up both 0.87 and 0.88 at once.

Which React version does Expo SDK 58 use?

React 19.3.0, with @types/react 19.3 and TypeScript 6.0 in the default template. SDK 57 used React 19.2.3.

Is Expo SDK 58 stable yet?

Not as of 21 September 2026. The beta opened on 15 September and Expo said it would run three to four weeks. expo@latest on npm is still SDK 57; SDK 58 is on the next tag. Expo moves to stable once React Native 0.88 ships.

Is SDK 58 a big breaking upgrade?

The biggest in several cycles. Two React Native versions, a removals-heavy 0.87, the Strict TypeScript API by default, the iOS scene life cycle, R8 on for Android release builds, and an Expo Router core rewrite. Budget real time rather than an afternoon.

Can an OTA update move an installed SDK 57 app to SDK 58?

No. SDK 58 has a different React Native runtime and different native code, so it needs a new binary. Keep EAS Update runtime versions aligned so SDK 58 JavaScript is never served to an installed SDK 57 build. The EAS Update vs Remote Config guide covers where that boundary sits.

Can I build an SDK 58 iOS app on EAS Build today?

You can build, but not against the iOS 27 SDK. As of 21 September 2026 the latest EAS Build iOS image ships Xcode 26.6. Expo has said Xcode 27 images are coming soon. Build locally with Xcode 27 if you need a genuine iOS 27 binary now.

Do I need to change anything for the iOS scene life cycle?

Not if you use Continuous Native Generation and keep custom native code in config plugins or Expo modules — npx expo prebuild --clean handles it. You do need to act if you maintain ios by hand, have a bare React Native app, or override UIApplicationDelegate methods directly.

My tab bar lost tabs after upgrading. Why?

SDK 58 shows only the screens you declare in the navigator. Add a <Tabs.Screen name="..." /> for every route that should appear, and options={{ href: null }} for the ones that shouldn't.

Should I install Expo CLI globally?

No. Use the project CLI through npx expo. For EAS, npx eas-cli@latest avoids depending on a stale global install.

Related Expo guides

• Expo SDK 57 upgrade guide: React Native 0.86 migration
• iPhone Duo support in Expo and React Native
• Build Liquid Glass UI with expo-glass-effect
• Expo Router Firebase Auth: protected routes and login flows
• EAS Build and Submit checklist for Expo React Native
• React Native Gesture Handler migration guide