Expo SDK 56 boosts cold start speed by 40% and impacts React Navigation

Expo SDK 56 arrived on May 21 2026, built on React Native 0.85 and React 19.2, and it is one of those upgrades where the headline numbers do the talking before you even read the migration guide. Faster cold starts, lower memory use, quicker iOS builds — plus Expo UI declared ready for production. If you ship a React Native app with Expo, this is the release that decides your upgrade quarter. Below is what SDK 56 actually ships, which numbers to trust and which to hedge, the one navigation migration that catches teams off guard, and an important footnote about a Hermes regression that Expo fixed one release later.

What SDK 56 actually shipsCopy Anchor Link

Start with the parts that are directly citable. The Expo SDK 56 changelog pins the release to React Native 0.85 and React 19.2, and it carries the line that matters most for component strategy going forward: Expo UI is now ready for production. That single sentence moves universal, cross-platform components from an experiment you watch to a primitive you can build on. If your team has been maintaining parallel iOS, Android, and web component variants, SDK 56 is the release that lets you start collapsing them.

The performance story is where you need discipline. The launch-period reporting around SDK 56 cited aggressive figures: roughly 40% faster Android cold start, materially shorter JavaScript garbage-collection pauses, around a third less memory use, and iOS builds completing in roughly half the time, with Hermes as the default engine. Treat those as reported-at-launch figures, not as guarantees for your app. Expo's own changelog culture is careful here — the SDK 54 changelog, for example, quotes a dramatic RNTester improvement (120 seconds down to 10 on an M4 Max) and then explicitly warns that your own app is unlikely to see anything near a much faster gain. Apply the same discount to SDK 56's numbers: the direction is real and the mechanism is real, but your mileage will vary with bundle size, native modules, and device class. Re-run your own cold-start traces before and after the upgrade and let your numbers, not the launch numbers, go into the sprint review.

What is not in doubt is the mechanism. SDK 56 sits on React Native 0.85 with React 19.2, continuing the line of work that SDK 54 started when it began shipping React Native on iOS as precompiled XCFrameworks. Each release in this line removes compiled-native-code waiting time from the critical path — first the framework core, then progressively more of the surrounding surface. Faster cold start comes from the same family of improvements: less work at launch, a tuned Hermes engine, and framework code that ships closer to its final form. When someone asks why the app "just feels snappier," that compounding is the honest answer.

# Upgrade path in a managed Expo project
npx expo install expo@^56
npx expo install --fix
npx expo-doctor

Run the doctor check before you touch navigation code. It catches the version skew — a stray react-navigation peer, a config plugin expecting an older SDK — that turns a fifteen-minute upgrade into an afternoon.

The Hermes footnote you should not skipCopy Anchor Link

Here is the part that republishing this guide in late 2026 obliges me to add. After SDK 56 shipped, Expo documented a Hermes V1 memory regression affecting worklets and Reanimated-heavy apps, and fixed it in SDK 57. The SDK 56 changelog carries that update inline. Practically, this means two things. First, if you are upgrading to SDK 56 today rather than back in May, budget a pass over your animation-heavy screens and confirm memory behavior on a real device before calling the upgrade done — or skip straight to SDK 57 if your app leans hard on Reanimated. Second, it is a reminder that pinning "Hermes is the default engine" as an unqualified win was always slightly premature; engine defaults interact with your dependency graph, and the changelog is the place you check, not the launch-day blog post. Shipping stale upgrade advice without this note would be exactly the kind of thing that costs a team a week of profiling.

The navigation migration that catches teams off guardCopy Anchor Link

The consequential buried change in SDK 56 lives in the routing layer. Expo Router is Expo's open-source universal routing library, and with SDK 56 the recommended posture is unambiguous: if you build on Expo plus Router, Router is your navigation surface. The practical consequence teams actually feel is import churn — screens and navigators wired directly against react-navigation packages need rerouting through the Router surface, and Expo ships a codemod to do the mechanical part.

Be precise about what changed and what did not. The runtime navigation API you call day to day stays consistent for typical patterns — stacks, tabs, deep links — as long as you run the migration. What breaks is direct imports from React Navigation packages scattered through your screens. The codemod covers the overwhelming majority of cases; the failures cluster where you would expect, in apps with deep custom integrations, hand-rolled navigation plugins, or flows that reach past Router into upstream React Navigation internals. If that describes your app, hold the upgrade until you have mapped every direct import, because each one is a compile error waiting for CI to find.

There is also a strategic read worth making explicit. Depending on Expo's maintained navigation surface means future upstream React Navigation features arrive on Expo's merge schedule, not yours. For mainstream apps that is a fine trade — one maintained surface, one upgrade guide, one team to blame. For apps whose differentiator is exotic navigation behavior, it is a real constraint to price in. Either way, pitching "we are waiting on upstream React Navigation" as a reason to sit out SDK 56 no longer parses; the decision is about your import graph, not the ecosystem's release calendar.

Should you upgrade to SDK 56 nowCopy Anchor Link

Upgrade if you care about launch time, memory headroom, or build feedback speed — especially on Android cold start and iOS build loops — and your navigation code runs through Expo Router or can be moved there with the codemod. For most teams the migration is measured in minutes: update the SDK, run the codemod, fix the stragglers, confirm on device.

Hold back, briefly, in exactly three cases. One, your app depends on upstream React Navigation internals outside what Router supports. Two, your animations stack is Reanimated-heavy and you have not yet verified behavior against the Hermes fix that landed in SDK 57 — in that case evaluate jumping straight to 57. Three, you are mid-release and cannot absorb even a small import migration; take the upgrade the week after you ship, not the week before. None of these is a reason to stay put indefinitely. SDK 56's performance line compounds with everything Expo has shipped since, including the precompiled-framework work from SDK 54, and sitting two SDKs behind is how teams end up doing painful jump upgrades later.

A note on how this connects to the broader architecture conversation: the fastest apps in 2026 are not just upgraded, they are structured so upgrades are cheap. A shared component system with named tokens, one navigation surface, and agent-readable conventions means each Expo release is a version bump instead of a project. That is the same thesis behind our guides to one component across web and mobile and the single-codebase shipping strategy — and once you ship, production error tracking like Sentry for React Native is what confirms the performance win on real devices instead of your M-series Mac.

ClosingCopy Anchor Link

Expo SDK 56 is a genuine performance release with one mechanical tax: faster starts, lower memory, quicker iOS builds, and a production-ready Expo UI, in exchange for moving your navigation imports onto the Router surface via the codemod. Hedge the launch-day percentages, mind the Hermes footnote that SDK 57 closed out, and run your own traces. Do that and the upgrade pays for itself in the first week of builds. When your codebase is agent-readable and component-driven, every future SDK bump gets cheaper — which is exactly what OTF kits are built to give you: a full-stack starting point your coding agent can upgrade, extend, and ship to production.

SourcesCopy Anchor Link

• Expo SDK 56 changelog — release date (May 21 2026), React Native 0.85, React 19.2, Expo UI production-ready, Hermes V1 regression note fixed in SDK 57.
• Expo Router introduction — Expo Router as the open-source universal routing library for Expo apps.
• Expo SDK 54 changelog — precompiled XCFrameworks on iOS, RNTester 120s to 10s with Expo's own caveat that real apps will see less.
• OTF kits — full-stack kits with agent-readable conventions that ship to production.