Migrating to React Native's New Architecture: A 2026 Field Guide

For years, "the New Architecture" was something React Native developers could safely ignore. That's over. The New Architecture became the default in React Native 0.76 and Expo SDK 52, the legacy architecture was frozen soon after, and as of React Native 0.82 the option to switch back has been removed entirely. If your app is still pinned to an old SDK, every month you wait makes the jump bigger.

I've now migrated my own apps — including Arrow Escape and Arrow Trails — and the honest summary is: it's less scary than the discourse suggests, but only if you do the audit before you flip the switch.

What actually changed under the hood

The New Architecture replaces the old asynchronous bridge with three pieces:

• JSI (JavaScript Interface) — JavaScript and native code call each other directly, synchronously when needed, instead of serialising JSON across a bridge.
• Fabric — the new renderer, which can measure and lay out views synchronously and works with React's concurrent features.
• TurboModules — native modules that load lazily and expose typed interfaces through codegen.

For app code, the practical effect is fewer frame drops around layout-heavy interactions, faster startup for module-heavy apps, and correct behaviour with React 18+ features like transitions. For library code, it means anything that touched the old bridge internals has to be updated — which is where migrations really go wrong.

Do you actually have to migrate?

Yes — the only question is when. The legacy architecture no longer receives fixes, React Native 0.82 runs exclusively on the New Architecture, and each Expo SDK supports a narrow window of React Native versions. Apple's and Google's store requirements also keep ratcheting minimum build tooling forward, so "stay on the old version forever" is not a real strategy for a shipping app.

The good news: if you're on managed Expo, most of the work is already done for you. Every expo-* package has supported the New Architecture since SDK 53, and Expo Go has run on it since SDK 52 — so if your app works in Expo Go today, your JavaScript is already running on Fabric.

Step 1: audit your dependencies first

Before changing anything, find out which of your libraries are ready:

• Check each native dependency on React Native Directory, which tracks New Architecture support per package.
• Flag anything unmaintained. A library with no commits in two years and old-bridge native code is the thing that will actually block you.
• Don't panic about every yellow flag: the interop layer lets many legacy native modules keep working unchanged, and the vast majority of actively maintained packages migrated long ago.

My rule from the migrations I've done: one afternoon of dependency audit saves a week of debugging mystery crashes later.

Step 2: flip the switch on a branch

On Expo, the migration mechanics are almost anticlimactic:

// app.json
{
  "expo": {
    "newArchEnabled": true
  }
}

Then rebuild your dev client and run the app. On recent SDKs this flag is already the default, so "migrating" is often just "upgrading the SDK and reading the warnings". Bare React Native apps follow the same idea with the newArchEnabled gradle property and the RCT_NEW_ARCH_ENABLED pod flag.

Do this on a branch, with a working build on main, so you can bisect whether a crash came from the architecture or from the SDK bump you did at the same time. Do not do both plus a dependency spring-clean in one commit — you want to know which change broke what.

Step 3: what usually breaks

Across my migrations and the ones I've done for client projects, failures cluster in four places:

1. Legacy native modules that reach into bridge internals. These either need an updated version, the interop layer, or replacement.
2. Layout edge cases — Fabric is stricter and more correct about Yoga layout, so code that accidentally relied on old measurement timing can shift by a few pixels.
3. Synchronous assumptions — code that assumed setState timing or relied on findNodeHandle tricks and UIManager calls.
4. Patched packages — any patch-package hacks against native code need re-checking against the new module format.

Budget honestly: a clean managed Expo app is a day or two including regression testing. An older bare app with several custom native modules is a one-to-three-week project, mostly spent in the modules, not in your product code.

The checklist I actually use

• Upgrade to the current Expo SDK on a branch; fix deprecations first.
• Run the dependency audit against React Native Directory; replace or upgrade blockers.
• Enable the New Architecture; build a dev client; smoke-test every screen.
• Exercise the "weird" surfaces: camera, maps, in-app purchases, deep links, push notifications — native-heavy features break first, JavaScript screens almost never do.
• Ship behind a staged rollout and watch crash reporting for a week before 100%.

If you'd rather start from a codebase where all of this is already done, that's exactly why I maintain the React Native Starter — it tracks the current Expo SDK with the New Architecture on, so new apps simply never have this migration in their future.