Expo SDK 56 just landed
Expo 56 is stable as of May 21, 2026. My first reaction: this feels less like a tidy SDK bump and more like Expo tightening the whole native-app feedback loop.
My quick take
Expo SDK 56 is exciting because the big wins are practical: faster builds, smaller updates, more native-feeling UI, and better tooling around the awkward parts of mobile development. The tradeoff is that teams using Expo Router, Expo Go, older iOS targets, or icon packages should read the breaking changes before they hit upgrade.
The headline upgrades are React Native 0.85 and React 19.2, but the interesting bit is the direction of travel. Expo is making native development feel less like a side quest from JavaScript and more like part of the normal app loop.
What stands out
Expo UI is becoming real product surface
Expo UI reaching stable status is the bit I am most curious about. SwiftUI and Jetpack Compose primitives in a cross-platform Expo app could reduce the usual compromise between "fast to ship" and "feels properly native". The new universal components also make it easier to avoid platform-specific splits for common UI.
Build time is finally treated as product quality
The iOS precompiled Expo packages are enabled by default, and EAS Build is also adding prebuilt artifacts for major community libraries such as Reanimated and Screens. That matters because build speed compounds. Every minute shaved off local and CI loops changes how often teams test, iterate, and ship.
Inline modules are a big bridge
Inline native modules feel like the sleeper feature. Being able to keep Swift or Kotlin modules close to the app code, with type-generation tools helping the JavaScript boundary, makes custom native work less ceremonial.
The Router change is the spicy one
Expo Router no longer sits on top of React Navigation. Strategically, that makes sense: Expo Router can optimize around file-system routing and native primitives without carrying a dependency shape that no longer matches its ambition.
Practically, this is also the part I would expect to create the most upgrade friction. If an app imports from @react-navigation/* while using Expo Router, I would plan time for the codemod and a careful pass through navigation edge cases.
What I would watch before upgrading
- Expo Go availability: Expo says SDK 56 Expo Go is not currently available through the Apple App Store or Google Play Store. Production teams should already be leaning on development builds anyway.
- Platform requirements: iOS, tvOS, and macOS minimums have moved up, and Xcode 26.4 is required for native iOS compilation.
- Breaking API shifts:
expo/fetchbecomes the default global fetch,expo-file-systemcopy and move methods are now async, and@expo/vector-iconsis no longer bundled through theexpopackage. - Router migrations: apps mixing Expo Router with direct React Navigation imports need extra attention.
Verdict
I would not blindly upgrade a shipping app on release day, but I would absolutely start a branch today. SDK 56 looks like one of those releases where the migration cost buys you a better daily development loop, not just a newer version number.
For greenfield work, it is more straightforward: start on SDK 56, try Expo UI early, use development builds rather than relying on Expo Go, and keep an eye on Router assumptions if you are bringing patterns across from older apps.