Expo SDK Upgrades: A Repeatable, Low-Drama Process

Expo ships around three SDK releases a year, and each one bundles a tested React Native version, updated Expo modules and, increasingly, changes that matter for performance and store compliance. Teams that upgrade every release spend a day or two each time. Teams that skip three SDKs spend weeks catching up.

This is a repeatable Expo SDK upgrade process for 2026: what to read first, the exact commands, the checks that catch problems early, and how to ship the result without breaking over-the-air updates. It's the Expo-specific companion to the general React Native upgrade process.

Key takeaways

• Upgrade one SDK at a time, and read that SDK's changelog and breaking changes before touching code.
• The core commands: npx expo install expo@^NN.0.0 --fix, then npx expo-doctor.
• Run the codemods Expo lists for the SDK; they handle mechanical migrations for you.
• Rebuild native projects (npx expo prebuild --clean if you use Continuous Native Generation) and make new development builds.
• A new SDK means a new native runtime: over-the-air updates for the old build won't apply to the new one, so plan channels and releases together.

Which SDK is current?

As of October 2026, Expo SDK 57 (released in June, on React Native 0.86) is the current stable SDK, and SDK 58 is in beta on React Native 0.88. Expo ships several SDKs a year, so the safe habit is to start each upgrade once the new SDK's first patch releases are out and your key libraries list support for it.

Before you start

• Check timing. Expo usually publishes a beta before each SDK and a stable release after. Upgrading a few weeks after stable gives libraries time to catch up. For example, SDK 58 entered beta in September 2026; production apps typically wait for the stable release.
• Read the changelog for the SDK you're moving to, including the "breaking changes" and "deprecations" sections.
• List your third-party native libraries and check each one supports the new SDK's React Native version.
• Make sure your current version builds and releases cleanly, so any new failure clearly belongs to the upgrade.

The upgrade, step by step

# 1. Move to the next SDK and align all Expo-managed package versions
npx expo install expo@^57.0.0 --fix

# 2. Check dependencies and configuration for known problems
npx expo-doctor

# 3. Run any codemods listed in the SDK changelog, for example (SDK 56):
npx expo-codemod sdk-56-expo-router-react-navigation-replace src

# 4. Regenerate native projects if you use Continuous Native Generation
npx expo prebuild --clean

Then create fresh development builds with EAS, run the app, and work through errors and warnings.

What usually needs attention

When something breaks

Most upgrade failures fall into a few patterns, and each has a quick first move:

• The native build fails. Read the first error, not the last; it usually names the library. Check that library's issues for the new SDK, upgrade it, or temporarily patch it.
• The app crashes on launch. Check native logs (Xcode console or Logcat). A missing native module after an upgrade often means a stale development build, so rebuild before digging deeper.
• A screen looks different. Compare against the React Native release notes for layout or text changes, and check whether a UI library changed its defaults.
• TypeScript errors everywhere. Expo SDKs often raise the TypeScript version; fix types in shared code first, since one fix can clear dozens of errors.
• expo-doctor warns about duplicate packages. Deduplicate with your package manager so only one version of each native package is installed.

Over-the-air updates and the new SDK

An SDK upgrade changes native code, so builds made with the new SDK have a different runtime version from the old ones. In practice:

• Updates published for old builds keep going to old builds, and the new builds only receive updates published from the new SDK.
• Keep a hotfix path for the old version until most users have updated through the stores.
• Use the fingerprint runtime version policy if you want Expo to work out compatibility automatically.

Testing the upgraded app

• Release builds on a real iPhone and a mid-range Android phone.
• Every critical flow: sign-in, payments, push notifications, deep links, camera, maps, background tasks.
• Startup time and scrolling, compared with the previous version.
• Store requirements that often arrive with SDKs, such as newer target API levels for Google Play.

From the field: I've shipped both Expo and bare React Native apps, and migrated eight to the New Architecture. Expo's SDK model makes upgrades far more predictable than hand-maintained native projects, as long as you take them one at a time and release each one before starting the next.

Expo Go and SDK versions

Expo Go supports one SDK at a time (the latest), so older projects can't run in the current Expo Go app. Since September 2026, Expo Go also asks you to sign in before running projects. For real projects, development builds avoid both issues: they're built for your app's SDK and include your own native code.

A sample schedule

FAQ

How do I upgrade my Expo SDK version?

Run npx expo install expo@^NN.0.0 --fix with the target SDK number, then npx expo-doctor, apply any codemods from the SDK's changelog, regenerate native projects with npx expo prebuild --clean if you use Continuous Native Generation, and rebuild with EAS. Upgrade one SDK at a time.

Can I skip Expo SDK versions?

You can, but it's riskier: you inherit several sets of breaking changes at once, and some codemods and migration notes assume you're coming from the previous SDK. Moving one SDK at a time, even if you do two in a row, makes problems easier to trace.

Why doesn't my app work in Expo Go after upgrading?

Expo Go supports only its current SDK, and projects with custom native code never run in it. Use a development build made with EAS for your app's SDK, which includes your native dependencies and matches your project exactly.

Will my over-the-air updates still work after an SDK upgrade?

Updates published from the new SDK reach builds made with the new SDK. Older builds keep receiving only updates that match their runtime version. Plan a store release for the new SDK and keep a hotfix path for the old version during the transition.

Next steps

If your Expo app is several SDKs behind, I can upgrade it step by step, with each version tested and released before the next, or keep it current on a retainer. Get in touch, or see my services.

Sources

• Upgrading Expo SDK, Expo
• Expo changelog, Expo
• Expo SDK 56, Expo
• Runtime versions, Expo
• Continuous Native Generation, Expo