How to upgrade to Expo SDK 56

The short version

SDK 56 is not just a package bump. It brings newer React and React Native versions, Router changes, platform requirement changes, and a handful of APIs that are easy to miss if you only run the install command and call it done.

1. Start from a safe branch

Before touching dependencies, make sure your current app is passing tests and committed. The upgrade is much easier to reason about when every change belongs to one branch.

If your project has native folders checked in, keep an eye on ios/ and android/ diffs throughout the process. Those diffs often tell you which config plugins or native settings changed.

2. Upgrade Expo packages

Install the SDK 56 version of the expo package first, then use Expo's package-aware installer to fix compatible Expo SDK package versions.

After the installer finishes, review package.json and your lockfile. If your app has custom native modules, config plugins, or pinned React Native libraries, check each library's SDK 56 support before moving on.

3. Run Expo Doctor

Expo Doctor is the quickest way to catch mismatched package versions, incompatible dependencies, and project config problems after the upgrade.

Treat warnings as upgrade work, not as noise. A dependency warning during an SDK upgrade is usually a sign that a package needs to be updated, replaced, or tested in a development build.

4. Handle Expo Router changes

If your app uses Expo Router, this is the part I would give deliberate attention. SDK 56 includes Router migration work for apps that mix file-based routing with direct React Navigation imports.

Run the official Router migration steps if your app imports from @react-navigation/*, uses custom navigators, or reaches into navigation internals.

Replace src with the directory or glob that contains your application code. After the codemod, manually test tab navigation, stacks, modals, deep links, auth redirects, and any custom header behavior. Navigation regressions tend to be subtle until someone tries a real user flow.

5. Check the common breaking points

• Expo Go: plan around development builds for serious testing. Do not rely on Expo Go availability for a production upgrade path.
• Platform requirements: confirm your team and CI machines satisfy the current iOS, Android, macOS, and Xcode requirements before cutting a release.
• Fetch behavior: test network-heavy screens because expo/fetch behavior is part of the SDK 56 change set.
• File system calls: check code that copies or moves files, especially if it expected synchronous behavior.
• Icons: verify any @expo/vector-icons imports and package assumptions after the dependency update.

6. Rebuild native development builds

After an SDK upgrade, restart the native side of the app rather than trusting an old development build. This matters even in managed apps because native dependencies and config plugins can change.

EAS development build command for Expo SDK 56

For an Expo SDK 56 app, the development build profile is still selected with --profile development. EAS reads the SDK version from your upgraded project dependencies and configuration, so you normally do not pass an SDK version flag to the build command.

If you are checking both platforms in one pass, run the iOS and Android development builds separately so each native target gets a fresh SDK 56 build artifact.

If you do not commit native folders, use the clean prebuild locally as a verification step, then discard generated files according to your normal workflow. If you do commit them, review the native diffs carefully.

7. Test before shipping

Once the app launches, run through a focused release checklist:

• Start the app with a cleared Metro cache.
• Test iOS, Android, and web if your app supports all three.
• Run unit, integration, and end-to-end tests that already exist.
• Check login, onboarding, navigation, media uploads, push notifications, deep links, and payment flows.
• Make a staging EAS Update and verify it lands on the right runtime version.

Final pass

When the branch is clean, compare the upgrade diff like a release reviewer. Package changes, native config changes, and app behavior changes should all be explainable.

My rule of thumb: if Expo Doctor is happy, development builds work on real devices, and your risky user flows have been tested, the SDK 56 upgrade is ready to move through normal release review.