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 main performance improvements in Expo SDK 56?

Expo SDK 56 substantially improves app startup time, memory usage, and build speed. According to first-hand reporting and Expo’s own release notes:

• Android cold start drops 40% — the update turns splash screens from a “one uncomfortable beat” into an instant open.
• Memory usage down about a third — measured “something like a third” less memory used after upgrade.
• iOS builds 50+% faster — the build step that usually blocks feedback cycles now completes in nearly half the time.
• React Native 0.85.2 — SDK 56 ships the latest stable React Native, bringing native performance and stability improvements rolled forward from upstream.
• Hermes v1 as default — JavaScript execution runtime is now v1 of Hermes across all new Expo projects (see below for what changed).
• 73% less GC pause (garbage collection) — Expo’s data shows a massive drop in garbage collection pause events in runtime JavaScript, making apps feel instant and smooth.
• No runtime navigation API breakage — despite changes under the hood, your navigation still works if you run the codemod.

In practice, the biggest visible win is the Android cold start. Users go straight from app icon to usable screen. The “white splash” that persisted in older SDKs is now gone, with JS code loading in less time, as measured directly after the upgrade.

Developers targeting Android get the most dramatic instant win, but the smoothing of GC pauses (73% less) and iOS build times (halved) improve the full stack. Performance improvements in Expo SDK 56 are not theoretical — they land immediately with measurable receipts.

How does Hermes v1 contribute to these performance gains?

Hermes v1 is the default JavaScript engine in Expo SDK 56, driving much of the upgrade’s performance jump. Prior to SDK 56, Expo projects used earlier versions of Hermes (or sometimes JSC, the JavaScriptCore engine), both of which offered slower JS execution and less efficient memory management.

Specifically, Hermes v1 introduces architectural and tuning changes that directly impact runtime and build metrics:

• Hermes v1 replaces v0.x — v1 brings optimizations in bytecode execution, heap management, and garbage collection algorithms.
• 73% reduction in GC pause — Expo’s official number, experienced in app launches and navigation: less jank, fewer long UX blocks.
• Better memory efficiency — about a third less memory consumed versus prior engine setup.
• Faster JS execution — direct result of improved internal operation scheduling and instruction decoding, benefiting both cold start and interactive transitions.
• Instant app opens — most of the Android cold start drop (40%) traces here. When Hermes v1 parses and executes your JS bundle more efficiently, your app simply starts faster and cleaner.

Code is unaffected, but engine swap can surface unexpected bugs if you had workarounds for old Hermes or JSC quirks. For the majority of projects, this switch is “just faster” — requiring no changes, but making every developer and user-facing wait shorter.

Bottom line: flipping Hermes v1 on by default is the technical lever that lets Expo SDK 56 post noticeable cold start and memory numbers, no rewrites required.

What happened to React Navigation in Expo SDK 56?

Expo Router no longer depends on React Navigation as an external library. Instead, starting with SDK 56, Expo now maintains its own fork of the key React Navigation packages. This fundamental architectural shift is not about runtime API changes — navigation code “just works” if you fix your imports — but you must update every usage of React Navigation to import from expo-router instead.

• Expo Router forks React Navigation — Expo now keeps an internal copy of the navigation primitives it builds on.
• Direct imports from @react-navigation/* break — if your code imports anything (Stack, Tabs, navigation containers) from React Navigation, those imports will 404 after the upgrade.
• Expo’s rationale — This is not a hostile fork. The official Medium post states Expo and React Navigation maintainers talked out a mutually healthy split, so both projects can evolve to match their use-cases (Expo focusing on file-based routing and quick iteration, React Navigation on the broader React Native ecosystem).
• Practical effect — You must reroute all navigation imports to expo-router, but your navigation patterns (Stacks, Tab navigation, etc.) and the runtime API are preserved.

If you rely on deep React Navigation APIs outside the surface area Expo Router maintains, you may need to audit for API drift — but for standard navigation schemas and most typical use, the import switch is enough. This move lets Expo advance the router without depending on React Navigation’s own upgrade cycles or priorities.

How do developers migrate their navigation code after upgrading?

The migration is straightforward but mandatory for anyone importing navigation primitives directly.

Step-by-step navigation migration after SDK 56:

1. Upgrade to SDK 56 as normal

• Adjust your package.json for expo@^56.0.0, update dependencies.

2. Find all imports from @react-navigation/*

• Any import such as:

  import { createStackNavigator } from '@react-navigation/stack';
  import { NavigationContainer } from '@react-navigation/native';

  will break after running the upgrade.

3. Run the Expo Router codemod

• Expo ships a codemod that rewrites imports for you:

  npx expo-router@latest migrate-navigation

• This tool scans your JS/TS files, updating imports:

  // Before
  import { createStackNavigator } from '@react-navigation/stack';
  // After
  import { createStackNavigator } from 'expo-router/stack';

• Same pattern for Tabs and NavigationContainer.

4. Test and commit changes

• The codemod is mechanical: verify that all navigation works as before. Functionally, Stacks, Tabs, and navigation context persist, and no runtime APIs have changed for the preserved surface.

5. Double-check deep API use

• If you use React Navigation APIs outside the standard Expo Router wrapper (advanced headers, custom actions, etc.), validate these work. The core navigation patterns are 1:1, but edge APIs or plugins may differ.

6. Preventative best practices

• Run the codemod immediately after upgrade to avoid runtime errors.
• Review your navigation layer in PR before merging.

Expo’s focus is on keeping the migration friction low — fifteen minutes for most projects, with the codemod removing manual grunt. If you skip the codemod, you will hit broken imports and immediate errors.

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.