Migrating to React Native's new architecture: what breaks and in what order

01What actually changed

The old architecture serialised every call between JavaScript and native as JSON over an async queue. That is why measuring a view, reading a native value or responding to a gesture involved a round trip you could not await synchronously.

JSI replaces that with direct references, so JavaScript can hold and call native objects synchronously. Fabric is the renderer built on it; TurboModules are native modules using it. Codegen generates the typed interfaces between them from your TypeScript specs.

The practical effect is that layout, gestures and native reads stop being asynchronous. Code that quietly depended on bridge timing - a setTimeout that happened to work, a measurement read a frame late - is where your regressions will come from.

02Sequence the migration around dependencies

Your own code is rarely the blocker. The dependency graph is.

Do the audit before you enable anything. A single unmaintained module that wraps a payment or analytics SDK can hold the entire migration, and finding that out after you have flipped the flag makes it much harder to reason about what broke.

• Inventory every native dependency and check its new-architecture support. Interop layers cover many, but not all, and not always correctly.
• Upgrade React Native itself first, staying on the old architecture. Separate the version upgrade from the architecture change so failures have one cause.
• Enable the new architecture in a development build only. Run the full app manually; automated tests rarely cover native surface.
• Fix or replace unsupported modules one at a time, shipping each replacement independently under the old architecture where possible.
• Flip the architecture last, behind a staged rollout, with the previous build ready to ship.

03The failures that are hard to diagnose

Most migration bugs present as timing changes rather than crashes, which is what makes them expensive.

Layout that was measured after a bridge round trip now resolves synchronously, so components that read dimensions during render may see different values. Animations driven off state updates may run a frame earlier. Code that relied on a native call resolving later can now see state it did not previously observe.

The other common class is a module that appears to work and silently no-ops. Interop shims can satisfy the interface without doing the work, so a permission request or analytics event stops firing without an error. Verify behaviour, not the absence of crashes.

04What it costs

For an app with a modest dependency list and an active team, this is typically two to four weeks including regression testing. The variable is not your code; it is how many unmaintained native modules you carry.

Apps that have been on an old React Native version for several years should expect the version upgrade itself to dominate. Upgrading across many majors and changing architecture in one release is the most common way this migration turns into a quarter-long project with no shippable intermediate state.

05Whether to do it at all

If your app is stable, shipping and not performance-constrained, there is no urgency in isolation. The reason to do it is that the ecosystem is moving; new library versions increasingly assume the new architecture, and the longer you wait the more of your dependency tree is frozen.

Treat it as maintenance debt with a rising interest rate rather than a feature. The cost grows with every version you skip.