Originally published on expo.dev/blog
By Keith Kurak
Expo SDK 56 is here, with support for React Native 0.85, and React 19.2. Android API level 36 and Xcode 26.4 and higher are supported. Also unchanged are the minimum supported operating systems: SDK 56 can build apps for Android 7+ and iOS 16.4 and higher. Check out the changelog to get a full picture of all that’s included. And here’s a short highlight video:
Each SDK undergoes extensive testing and a beta test period, where the Expo team and the community collaborate to find issues that might stand in the way of a fast and smooth upgrade for others. A lot of Expo engineers maintain our own apps and try to upgrade those as soon as the beta is out.
Nonetheless, there’s practically infinite possibilities out there. Every app is unique, and has its own complexities that will need to be accounted for when upgrading. Therefore, we wanted to highlight some specific key changes that may affect your upgrade to SDK 56, as well as some evergreen advice when it comes to upgrading to the latest Expo SDK.
Key things to know as you upgrade to SDK 56
Power your SDK upgrade with Claude Code
At Expo, we use Claude Code in our day-to-day work. Based on our experiences, we’ve published some skills to help with common tasks within Expo apps in the expo/skills library. One of these skills is for upgrading to the latest Expo SDK version. In addition to the basics like updating package versions, it handles things like breaking changes, cleaning up outdated configurations, and more.
Within Claude Code on your terminal, run
/plugin marketplace add expo/skills
to add the skills marketplace to Claude, and then
/plugin install expo
After restarting Claude, you can ask it in plain language to upgrade your SDK. If it’s installed correctly, you should see Claude reference the skill as it gets started:
You can also import Expo skills into other agents via
bunx skills add expo/skills
As always, do your work on a separate branch, and review your code before merge and deploy. LLMs are amazing, but Claude and the Expo upgrade skill can’t be aware of every possible scenario. Human developers are a vital part of this workflow!
Faster native builds
To speed up iOS builds, SDK 56 ships prebuilt XCFrameworks for our most complex Expo modules on iOS. This is enabled by default both locally and on EAS Build — no configuration required. To opt out, set the EXPO_USE_PRECOMPILED_MODULES environment variable to 0 (for local builds), and also as an EAS environment variable (for EAS Build).
For Android, a new opt-in android.usePrecompiledHeaders option in [expo-build-properties](https://docs.expo.dev/versions/v56.0.0/sdk/build-properties/) applies CMake precompiled headers to the C++ codegen output for every autolinked native module, dramatically cutting CMake compile times on Android.
Expo Go update
Expo Go for SDK 56 is not available on the Apple App Store or Google Play Store. We do not have a timeline for when they will be, and we will update the SDK 56 changelog when we have more news to share. For more information, you can refer to “Expo Go and the App Store in May 2026.”
The Expo Go app is our tool for getting started quickly, it's an educational tool to help you learn to build on mobile. We encourage you to take advantage of this transition period to migrate your project to using a development build, which provides you with everything that you need to build an app that you ship to stores.
You can install Expo Go for SDK 56 from Expo CLI directly on Android devices. For iOS, you can use the TestFlight External Beta or the eas go command to create an Expo Go build for SDK 56 and upload it to your own TestFlight team.
Hermes bytecode diffing for updates is enabled by default
In SDK 55 we introduced opt-in Hermes bytecode diffing for expo-updates and EAS Update: instead of downloading a full bundle on every update, the client downloads a binary patch against the previously installed bytecode.
Diffing is on by default in SDK 56. To opt out, set "enableBsdiffPatchSupport": false in the updates block of app.json. Learn more in the [expo-updates](https://docs.expo.dev/versions/v56.0.0/sdk/updates/) API reference.
Inline Expo Modules
You can now define Expo modules directly within your project structure, alongside your JavaScript and TypeScript code. We call these inline modules, and they make experimenting with native code easier than ever. You can develop inline modules from Android Studio, Xcode, or any other IDE as they are part of your project structure. Check out the inline modules reference and the tutorial for more information.
Tips for upgrading your Expo SDK
We have written up detailed advice for troubleshooting issues found during an upgrade. This includes considerations for both before and during your upgrade, with a list of suggestions, starting with the quickest/easiest to try. We recommend reading the entire guide, but we wanted to highlight a few key items in brief here:
Use the upgrade skill!
It’s so nice, we’ll say it twice: Add the expo/skills library to your preferred LLM and let it do the upgrade for you.
Troubleshoot with Expo MCP
Expo MCP now includes more tools to help you troubleshoot your upgrade alongside Claude Code, Codex, Cursor, and others. If one of your EAS builds fails, use the build_logs tool to pull down the build logs for analysis with AI. If you install the expo-mcp package, you can use the collect_app_logs tool to pull native logcat / macOS console logs from your emulator/simulator.
Check the changelog
Most SDK releases will have a list of known breaking changes, or notable changes where you may need to tweak configuration for a scenario specific to your app. The best time to read the changelog and breaking changes is before you upgrade, so you can make those tweaks before you test, but the next best time to read it is after you upgrade, particularly if you see a compilation error or crash.
Using development builds over Expo Go
Upgrades are best taken when you don’t feel rushed to complete them. As Expo Go automatically upgraded to the latest version after the SDK release on your phone, you may have noticed that your app no longer worked in Expo Go, and felt that you needed to upgrade right away in order to keep working on features.
Development builds help reduce the temperature, giving you time and space to take on an upgrade while not interrupting ongoing feature work. A development build works a lot like Expo Go, allowing you to scan a QR code to work on your code locally without rebuilding. But it’s your own app, so it will not get upgraded when a new version of Expo Go is released.
If you still feel that you need to use Expo Go, know that you don’t necessarily have to use the latest version on the Play and App Stores. You can go to https://expo.dev/go and download previous versions for use on Android devices and iOS simulators. Unfortunately, due to App Store restrictions, this does not work on iOS devices.
Still, another reason to migrate to a development build is because Expo Go is quite limited in how it can replicate your production app, leading to issues where it works in Expo Go but not when you build your production app. Expo Go can run your JavaScript, but it cannot apply most of your app.json / app.config.js configuration, because that would require modifying native code. In short, Expo Go can’t contain nearly everything that’s unique and special about your app. Development builds can. There's plenty of headroom in the Free plan to make some development builds, or you can build locally npx expo run:android or npx expo run:ios.
New Architecture advice
Expo SDK 54 was the last SDK to support the Old Architecture. SDK 55+ / React Native 0.83+ only support New Architecture. Therefore, if you haven’t upgraded to the New Architecture yet, now is definitely the time! A number of the latest versions of major packages, such as react-native-reanimated v4 and @shopify/flash-list v4, only support New Architecture.
Avoid upgrading both your Expo SDK and adopting New Architecture at the same time. This makes it more difficult to isolate any issues. Compared to upgrading your Expo SDK, adopting New Architecture is the bigger change, so any issues are likely related to that- but it will be hard to tell if you upgrade to both at the same time.
We recommend first upgrading to the New Architecture on SDK 54 and then creating a development build. Test that, using our New Architecture troubleshooting guide to help if you run into any issues. After you’ve verified things are working just by upgrading to New Architecture, upgrade to SDK 56 and make a new development build. Now, you’ll just be testing your SDK 56 upgrade in isolation.
Check the troubleshooting guides
We have a landing page of our most popular troubleshooting guides that you can browse depending on your issue. If your issue is an error when building, you’ll want to take different steps compared to a crash or performance issue. Even if you don’t fully get to the root cause, using a tool like ADB Logcat or macOS console to find a native error that the operating system reports from a crash can be very helpful as you engage in further troubleshooting or ask others for help.
Reach out if you need a hand!
We appreciate your bug reports and feedback! The best way to surface an issue is and will always be a Github issue with a minimal reproduction, where you send us a link to a Github repo based on the default project template created with npx create-expo-app , plus just enough code to reproduce the issue.
A minimal reproduction ensures that our team can see exactly what you’re seeing and gives us a way to test that our fix will work for you. Even if that seems like a lot to do, often spending 15 or 30 minutes trying to make a minimal reproduction is more effective than hours spent debugging on your actual app, where there are a lot of moving pieces and it’s more difficult to isolate issues. AI tools like Claude can even help make the minimal reproduction for you.
We also understand the value in discussing an issue in the moment, even before you’re ready to try to reproduce it. Other developers may be experiencing the same thing and already have an answer. Discussions about issues on Discord, Reddit, Bluesky and elsewhere can result in a sort of collaborative virtual rubberducking where we find the answer together while talking through it.
We encourage you to post screenshots or videos of the issues you’re facing, or at least descriptions of what exactly you’re seeing, what platforms are affected, etc. so we can see what is broken and help the community think through how to isolate that issue and find a solution. If you have detailed feedback about the upgrade process that doesn’t fit neatly into a minimal reproduction of a single issue, we’d love to hear about it, as well. Besides social forums, we always have someone checking on the messages received from our support page.
Happy upgrading and we hope you love SDK 56!
