For years, "New Architecture" was React Native's most-discussed feature that most apps quietly ignored. That window closed. React Native 0.76 (October 2024) made it the default for new projects. React Native 0.82 (October 2025) removed the ability to opt back out — the newArchEnabled=false flag is now ignored on both platforms. React Native 0.85 (April 2026) went further and deleted the legacy bridge code from the codebase, with no fallback or interoperability layer left to fall back on.

If you're still running an app built before this shift, the question isn't whether to migrate anymore. It's how urgent it is for you specifically — and that depends more on your dependency list than on your own code.

What actually changed, in plain terms

Three components replaced three older ones:

  • JSI replaced the Bridge. The old Bridge sent everything between JavaScript and native code as serialized, asynchronous JSON messages — batched, queued, and a well-known source of jank under load. JSI (the JavaScript Interface) lets JavaScript hold direct references to native objects and call them synchronously when needed, cutting out the serialization step that caused most of the historical performance complaints.
  • Fabric replaced the legacy UI Manager. Fabric is the new rendering layer — it uses the same JSI connection to build and update the view tree with less overhead and better support for concurrent React features.
  • TurboModules replaced legacy native modules. The old system loaded every native module at app start, whether or not it was used. TurboModules load lazily, on first access, which is a meaningful part of the cold-start improvement teams report after migrating.

Is your app on borrowed time?

Answer honestly and we'll tell you where you actually stand.

Interactive · migration urgency check

What migration actually takes

The range we see reported and that matches our own work: a small app with few custom native modules can migrate in about a week. A larger app with several custom native modules, or dependencies that haven't been touched in a while, is more realistically four to eight weeks. The JavaScript-side changes are rarely the bottleneck — auditing and, where necessary, replacing or forking unmaintained native modules is what actually determines the timeline.

For a new project starting today, the practical advice is to sidestep the question: start with Expo. The managed workflow defaults to the New Architecture, Expo Modules gives you a clean TypeScript API for any native code you do need to write, and the surrounding ecosystem — libraries, tooling, documentation — is now built and tested against the current architecture first.

The migration checklist, in order

StepWhat it actually involves
1. Audit native modulesList every third-party native dependency and check its New Architecture support status. This list — not your app code — sets the real timeline.
2. Handle the gapsFor any unmaintained module with no New Architecture support: find a maintained alternative, fork and patch it yourself, or budget time to rewrite the functionality.
3. Upgrade React Native / Expo SDKMove to a version where the New Architecture is stable and well-documented rather than jumping straight to bleeding-edge.
4. Enable and buildFlip the New Architecture on in a branch and get a clean build on both platforms before touching functional QA.
5. QA native-adjacent features hardestMaps, camera, biometrics, push notifications and any custom native UI are where regressions actually surface — budget real device time here, not just simulator passes.

Is the performance gain real?

Directionally yes, though the exact number is workload-specific and you should treat any single figure as a case study, not a guarantee. Migrations reported in the wild commonly cite meaningfully faster cold starts, faster initial rendering and lower memory use — the pattern lines up with what changed structurally: TurboModules loading on demand instead of all at once, and JSI removing the old Bridge's serialization overhead on every native call. Apps that lean heavily on custom native modules or frequent native calls tend to see the largest improvement; a mostly-JavaScript CRUD app will notice less.

The part people underestimate: this isn't a library upgrade you run and walk away from. The riskiest failure mode is an unmaintained native dependency that silently breaks in ways that don't show up until a specific device, OS version or edge case in production. Budget the native module audit as real engineering work, not a checkbox before the "actual" migration starts.

Frequently asked questions

If you are on React Native 0.82 or later, you already have — the old architecture cannot be re-enabled from that version onward. If you are on an older version, migrating is no longer optional in any practical sense: 0.85 removed the legacy bridge code and its interop layer entirely, so every version after it requires the New Architecture to run at all.
For a small app with few custom native modules, real-world migrations have taken about a week. For a larger app with several custom native modules or ageing dependencies that need auditing or replacing, four to eight weeks is a more realistic range. The native module audit is almost always the long pole, not the JavaScript side.
JSI replaced the old asynchronous Bridge with direct JavaScript-to-native calls, removing a serialization step that caused most cross-platform performance issues. Fabric replaced the legacy UI manager as the rendering layer. TurboModules replaced legacy native modules, loading lazily instead of all at once on app start.
Direction, yes; the exact number is case-specific. Case studies from real production migrations report meaningfully faster cold starts and lower memory use, largely because TurboModules load on demand instead of upfront and JSI removes the old bridge's serialization overhead. Apps with heavy custom native module usage tend to see the largest gains.
Audit every third-party native module for New Architecture support first — that list, not your own code, usually determines the timeline. Confirm your React Native and Expo SDK versions, budget real QA time for native-adjacent features like maps, camera and biometrics, and treat any library with no New Architecture support as a replace-or-fork decision made early, not discovered late.
HS
Het Soni
Founder & Lead Engineer, Soni Consultancy Services