How to upgrade to SDK 58

SDK 58 is out, and it brings iOS 27 support and React Native 0.88. The SDK 58 changelog has the full release details.

Let’s get your SDK 57 upgraded! The quickest way is to hand the upgrade to your coding agent with the Expo upgrade skill, so we’ll start there. If you’d rather do it by hand, the manual steps follow, and then we list the changes most likely to affect your app.

Recommended: upgrade with your coding agent

A skill is a set of instructions your coding agent can read when it takes on a task. The expo-upgrade skill gives it guidance for SDK upgrades, including dependency checks and migrations, such as patches you no longer need and APIs that have been removed.

Follow the Expo Skills installation docs to set up the skills for your coding agent. Once that’s done, commit your work and tell your agent: “Upgrade this project to the latest Expo SDK”. It loads the skill and takes it from there.

Upgrade by hand

To run to the latest SDK 58 packages manually, run these commands:

The first upgrades expo and aligns your other dependencies with SDK 58. The second checks for common project problems.

Be sure to check the changelog for the full list of changes and deprecations that may affect your app.

If you don’t use Continuous Native Generation and commit your android and ios folders to source control, be sure to upgrade those native projects, as well. Follow our Native project upgrade helper to see exactly what changed. This guide includes a prompt to give to your Agent to automate the upgrade, complete with the full diff from your current to target SDK version.

EAS Build images and Expo Go

On EAS Build, the sdk-58 and latest iOS image aliases now point to the Xcode 27.1 image. If you have set a specific image in eas.json, change it to one of those. Alternatively, remove it and use the default. The build infrastructure reference lists every image.

The new Expo Go comes to the App Store and Google Play in the next few weeks, and it supports only SDK 58. npx create-expo-app recommends SDK 58, so use a development build to run your new project. If you want to stay on Expo Go until the new version ships, pick SDK 57 when the command asks. If you ship a production app, a development build is where you should be anyway.

Notable changes

React Native types and removed APIs

SDK 58 upgrades React Native from 0.86 to 0.88, so it includes the changes from both React Native 0.87 and React Native 0.88.

The Strict TypeScript API is now the default. Deep imports from react-native/Libraries/* will now show as type errors, and refs must use instance types such as ViewInstance and TextInputInstance. Run your type check early. The Strict TypeScript API guide covers the changes, and you can hand the work to your agent with the migrate-to-strict-api skill.

Some APIs have been removed, including:

• InteractionManager. Use requestIdleCallback instead.
• The Touchable root export. Use ViewProps if you were extending Touchable as a type.
• The animated prop on Modal.
• The backgroundColor, translucent, and networkActivityIndicatorVisible props on StatusBar. They were already deprecated.

ImageBackground is deprecated in favor of a View with an absolutely positioned Image.

SDK 58 does not yet support macOS. Support will return when react-native-macos is updated to at least React Native 0.86.

iOS scene life cycle and orientation

The new iOS 27 SDK makes significant changes to support new form factors like the iPhone Duo, and Expo SDK 58 is ready for it. npx expo prebuild has been updated to support the required UIKit scene-based lifecycle, and now generates SceneDelegate.swift and a UIApplicationSceneManifest entry in Info.plist, and the scene delegate creates the window instead of didFinishLaunchingWithOptions. Expo forwards URL, user activity, Handoff, life cycle and quick action events to ExpoAppDelegate subscribers, so config plugins and modules built on them keep working.

If you maintain your ios directory by hand, have a bare React Native app, or override app delegate methods in AppDelegate.swift, follow the scene life cycle migration guide. If you enabled ios.enableSceneSupport with expo-build-properties on SDK 57, remove it. SDK 58 includes scene support.

iOS 27 also makes iPhone apps resizable. requireFullScreen no longer opts your app out, and ScreenOrientation.lockAsync may have no effect while the app is resizable. If you rely on a fixed orientation, read orientation locks on iOS 27 and later.

Expo Router

The navigation core was reworked, and most apps won’t notice. If you built a custom navigator or import from expo-router/react-navigation, some APIs have moved or been removed, and new navigators should use createStandardRouterNavigator or integrateWithRouter instead of withLayoutContext.

Other changes to check, including:

• Native tabs import: expo-router/unstable-native-tabs is now expo-router/native-tabs.
• Server output: when web.output is not set, projects use "server", which renders HTML on each request. To keep the SDK 57 behavior, set web.output to "static" and enable the apiRoutes option of the expo-router config plugin.”
• Async routes on web: route files are split into separate chunks. Set asyncRoutes: { web: false } to turn this off.
• Stack header on iOS 26 and later: the header is transparent with Liquid Glass by default, and screen content goes under it. See Review the iOS header appearance in the guide.
• Optional dependencies: expo-symbols and @expo/ui are optional peer dependencies. On Android, install expo-symbols if you use NativeTabs.Trigger.Icon with the md prop, and @expo/ui if you use Stack.Toolbar.

The Router migration guide covers every change, including static export metadata, custom routers, and the removed expo-router/react-navigation exports. Read it even if you only use the built-in navigators.

Android release builds

The Android template now enables R8 in release builds by default. Some of you may have already turned this on to address warnings on Play Store submissions. You can opt out by setting android.enableMinifyInReleaseBuilds to false with expo-build-properties. This default should work fine for most apps, though apps using libraries that rely on reflection may need ProGuard keep rules, which can also be set via expo-build-properties.

New fingerprint defaults to reduce native rebuilds

Bumping a version, or changing files inside node_modules, no longer means a new fingerprint. SDK 58 defaults fingerprint to the balanced preset. It ignores common cases where you may have previously used a source skip, like updating version in app.json, and hashes native modules by package name and version instead of their files and directories. Learn more about fingerprint presets if you want a different tradeoff.

If something goes wrong

Start with Troubleshooting your SDK upgrade, then the troubleshooting guides for the problem you’re seeing. A failed build needs a different approach from an app that crashes or runs slowly.

For crashes, native logs usually explain what happened. Read them with ADB Logcat on Android or Console on macOS for iOS devices. Even before you find the cause, those logs are useful to share when you ask for help.

Let us know how it goes

If you hit a bug, open a GitHub issue with a small project that reproduces it. Start from npx create-expo-app and add just enough code to show the problem. Include the repo link and the exact package versions you’re using. A small reproduction helps us confirm a fix, and building one often turns up the cause, since there’s less code to look through.

If you’re still working out what’s wrong, ask on Discord, where we also hold office hours on Wednesdays at 12:00 PM Pacific. Share the error, the affected platform and the steps that lead to it. Our support page has more ways to get help.

If the upgrade skill missed a migration or made a change it didn’t need to, report it in the Expo skills repository.

Happy upgrading!