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

How Expo SDK 56 Boosts Performance and Changes React Navigation with Expo Router Fork

Performance improvements in Expo SDK 56 are real, immediate, and measurable. If you care about cold start speed, memory use, or the reliability of your navigation layer, this upgrade is not abstract — it’s a visible, direct win. The official numbers are aggressive: reported 40% reduction in Android cold start, 73% less JS garbage collection pause, ~33% less memory used, and iOS builds completing over 50% faster. Hermes v1 is now the default engine. One change is buried, but consequential: Expo Router now ships with a maintained fork of React Navigation. That means a migration — imports break, a codemod is required — but the runtime API stays consistent. Below, the facts on the speed, the technical mechanisms, the navigation fork, and how to keep your project moving forward without getting tripped up.

What are the real-world developer experiences and tradeoffs?

The emotional arc and on-the-ground tradeoffs are direct. Developers see concrete, positive improvements: apps start 40% faster on Android, with the classic “splash screen pause” removed. Memory and build feedback loop times improve, landing especially for iOS targets (build times slashed by half).

“At first, I didn’t believe the numbers…but they were real. Android cold start dropped about 40%. Memory's down something like a third. iOS builds…are running fifty-odd percent faster.”

The navigation change, though, is a left hook even for experienced teams:

• Pro: App performance is universally better. Launches are instant, interaction is snappier, GC pauses are less obvious.
• Pro: The runtime navigation API doesn’t break (as long as you follow the codemod migration).
• Con: Every direct import from React Navigation fails. You must run a codemod; skipping means errors everywhere.
• Con: There’s subtle discomfort knowing you now depend on Expo’s fork. If you need features React Navigation adds later, you wait for Expo to merge.
• Emotional toll: “It’s not the migration that’s been sitting with me. It’s what it means. React Navigation…like the floor under your feet…Now Expo maintains its own copy.”

For most, the migration is fifteen minutes of inconvenience for a net gain: visible speed and the confidence of a maintained navigation surface. For edge users, you may need to revisit choices around custom navigation flows.

Should you upgrade to Expo SDK 56 now?

Upgrade to Expo SDK 56 if you care about faster start times, reduced memory, and quicker build feedback — especially on Android and iOS. For most teams, the only migration step is rerouting navigation imports. The codemod covers 99% of cases; runtime API differences are minimal for typical navigation patterns.

Hold back only if your app uses deep, custom integrations with React Navigation outside what Expo Router supports, or if you have heavy custom navigation plugins dependent on upstream React Navigation changes. For nearly every mainstream mobile project, the benefit to users (and to dev iteration speed) is worth the import migration.

The navigation fork is now durable: if you’re building for Expo+Router, pitching future React Navigation upgrades as a blocker no longer makes sense.

Closing

Expo SDK 56’s 40% faster Android cold start, 73% less GC pause, and over 50% speedup of iOS builds are concrete, immediate wins driven by its default use of Hermes v1 and integration of React Native 0.85.2. The switch to maintaining a forked copy of React Navigation in Expo Router means one mechanical update: run the codemod, fix imports, and you keep moving. The biggest gain? Snappier, more reliable apps and a navigation story built to move at Expo’s pace — not stuck waiting on upstream. Ship faster, with fewer surprises, and prove the performance receipts on every device.

---

Originally published at otf-kit.dev — full-stack kits your AI coding agent can actually ship to production. See the kits →