Expo SDK 58: what to check before upgrading

Expo SDK 58 is out. Expo announced the stable release on 15 October 2026, with support for iOS 27. Its supported dependency versions include React Native 0.88 and React 19.3.

Android home-screen widgets and the expanded Expo UI components give teams some new features to explore. For an app already in customers' hands, though, we'd start the upgrade with the routes, native code and release configuration it already uses. There is enough changing in those areas to warrant a separate piece of work.

Start from a build you can reproduce

Commit a working version before changing dependencies. Keep the lockfile, build profile and current native build available so there is something concrete to compare against.

For an app moving from SDK 57 to 58, the manual upgrade steps begin with:

npm install expo@^58.0.0
npx expo install --fix
npx expo-doctor

Use the equivalent command for your package manager. If the app is several SDKs behind, work through the intervening versions. A smaller dependency jump makes a new failure easier to locate.

Also check how the native projects are maintained. Generated ios and android directories follow a different upgrade process from directories with hand-maintained native changes. Read that part of the guide before regenerating anything.

Decide how the web build should run

If the app also runs in a browser, check web.output early. Expo Router projects on SDK 58 default an unset value to server. Server output now produces HTML on each request. Apps relying on the earlier prerendering behavior need an explicit configuration decision. The Router migration guide describes the change.

For the previous combination of prerendered pages and API routes, Expo documents:

{
  "expo": {
    "web": {
      "output": "static"
    },
    "plugins": [["expo-router", { "apiRoutes": true }]]
  }
}

Those API routes still need a server. Check the hosting setup before copying the configuration. If rendering on each request suits the app, keep server output and test that deployment path.

Then open a detail-page URL directly, refresh it and repeat while signed out. Inspect the returned HTML as well as the rendered screen. These are useful checks for a support dashboard or a public booking page that people often reach through a saved link.

Read the first TypeScript errors

The React Native upgrade also brings the Strict TypeScript API into projects moving from SDK 57. React Native's migration guide explains two changes worth looking for: imports into react-native/Libraries/* fall outside the public type interface, and component refs use instance types such as ViewInstance and TextInputInstance.

Run the project's type check before making unrelated UI changes. If a shared input wrapper reports an error, fix its types and inspect the screens that use it. Adding casts throughout those screens makes the next review harder.

There are runtime API removals to review too. Expo's SDK 58 upgrade notes list InteractionManager among them and point to requestIdleCallback. Read what the existing callback does before replacing its scheduling. Work that was tied to a navigation interaction deserves a check during that interaction.

Exercise the iOS entry points

SDK 58's iOS setup uses the scene-based application lifecycle. Teams with custom AppDelegate.swift code or manually maintained native projects should follow Expo's scene migration instructions.

A useful test starts outside the app. Open a password reset link with the app closed, complete the flow and go back. Try a notification that leads to a particular record. Repeat after signing out. This covers the handoff between the operating system, navigation and session handling.

Give resizing some time too. Expo notes that on iOS 27, requireFullScreen no longer prevents an app from being resized. Try the busiest form in a narrow window with its keyboard open. Check that the final field, validation message and submit button can all be reached.

Build the new native runtime

An SDK upgrade changes the native code inside the app. It needs a new native build. Publishing JavaScript through EAS Update cannot install that native code into an older binary. Expo's runtime version documentation explains how builds and updates stay compatible.

Before publishing, check the runtime version policy and the channel used by the candidate build. Test an update against a preview build with the intended runtime. Keep a record of which binary received it, particularly when older app versions are still in use.

Measure the build changes on your project

SDK 58 changes the default fingerprint preset to balanced, reducing some rebuilds caused by changes such as an app version bump. It also offers an experimental Rust-based Metro transformer. Expo reports faster cold bundling in its own tests.

Record a cold bundle and a repeat bundle with the project's actual configuration before deciding whether to adopt the experimental path. App launch time and scrolling need their own measurements.

For the first internal release, keep a short record of the journeys tested, device and OS coverage, and any unresolved issue. That gives the person approving the rollout something specific to review. New widgets and UI components can have their own pull requests once the existing app is running reliably on 58.