React Native New Architecture Migration 2026: Cost, Timeline, Gotchas

This guide is for CTOs, product owners and React Native developers worldwide who maintain an app that has not been upgraded in a year or more. After reading it you will understand what changed in the New Architecture, which versions matter, the order of migration steps, the problems that usually take the most time, and realistic cost and timeline bands to plan a budget.

What is the React Native New Architecture?

The New Architecture replaces the old asynchronous bridge with JSI, a direct interface between JavaScript and native code, along with the Fabric renderer, TurboModules for native modules, and Codegen for type-safe bindings between the two sides.

• JSI (JavaScript Interface): lets JavaScript hold references to native objects and call them directly, without serialising every message to JSON.
• Fabric: the new rendering system, which supports React's concurrent features and synchronous layout reads where needed.
• TurboModules: native modules that load lazily and are called through JSI.
• Codegen: generates native interface code from typed JavaScript specs, catching mismatches at build time.
• Bridgeless mode: the app runs without the legacy bridge at all.

For the official background, see About the New Architecture on reactnative.dev.

Which React Native version removed the Legacy Architecture?

React Native 0.82, released in October 2025, was the first version that runs only on the New Architecture, and 0.84, released in February 2026, stopped including Legacy Architecture code in iOS builds and removed many legacy Android classes.

Version	Released	What changed for the architecture
0.76	October 2024	New Architecture enabled by default for projects
0.80	June 2025	Legacy Architecture declared frozen; DevTools warnings for APIs that will not work in the New Architecture
0.81 / Expo SDK 54	2025	Last versions where you can still turn the New Architecture off
0.82	October 2025	New Architecture only; setting newArchEnabled to false is ignored; interop layers kept
0.84	February 2026	Hermes V1 default; legacy code no longer in iOS builds; legacy Android classes removed; Node.js 22.11 or later required

The React Native team says the interop layers, which let many older libraries run on the New Architecture, will stay for the foreseeable future. That is why plenty of apps migrate without rewriting every dependency.

Why migrate in 2026 if the old app still works?

An app frozen on an old React Native version gradually loses the ability to ship updates, because store target API rules, operating system changes and library updates all assume recent versions, and the Legacy Architecture no longer receives fixes.

Google Play is the clearest deadline. Since 31 August 2026, new apps and updates must target Android 16 (API level 36), with extensions available to 1 November 2026, according to Google's target API level page. Old React Native versions are not tested against new target levels, so a store-driven update often turns into a full upgrade anyway. Doing the architecture migration in the same project avoids paying twice.

There are also gains: faster startup in many apps, synchronous native calls where you need them, access to React 19 features, and a dependency tree that library maintainers still support.

React Native New Architecture migration steps

The official recommendation is to upgrade first to React Native 0.81 or Expo SDK 54, enable the New Architecture there, verify the app, and only then move to 0.82 and later.

1. Freeze features for the migration window and tag the current release so you can roll back.
2. Upgrade in steps to 0.81 using the official upgrade helper diff, one or two minor versions at a time if you are far behind.
3. Audit every dependency for New Architecture support (see the next section).
4. Enable the New Architecture on Android and iOS, or in Expo config.
5. Fix runtime warnings shown in React Native DevTools about APIs that will not work.
6. Convert custom native modules to TurboModules and custom views to Fabric components with Codegen specs.
7. Run a full regression on real low-end and high-end devices.
8. Upgrade to the current release, raise the target SDK, and ship through a staged rollout.

Enabling the New Architecture on 0.81

On Android, set the flag in android/gradle.properties:

newArchEnabled=true

On iOS, reinstall pods with the flag set:

cd ios
RCT_NEW_ARCH_ENABLED=1 bundle exec pod install

In an Expo project on SDK 54, set it in app.json:

{
  "expo": {
    "newArchEnabled": true
  }
}

Library audit: the step that decides your timeline

The single biggest variable in migration effort is how many third-party libraries and in-house native modules lack New Architecture support, so list every dependency with native code before you estimate anything.

Dependency status	What to do	Effort
Supports the New Architecture in a recent version	Upgrade the library	Low
Works through the interop layer	Keep, test carefully, plan replacement	Low to medium
Unmaintained, no support	Replace with a maintained library or fork and patch	Medium to high
Your own native module	Rewrite as a TurboModule with a typed spec	Medium per module
Your own native UI component	Rewrite as a Fabric component	High per component
Vendor SDK (payments, maps, KYC)	Check the vendor's current React Native package	Varies

The community-maintained React Native Directory flags New Architecture support for many packages, which is a fast first pass. Confirm on the library's own changelog before you trust it.

Common gotchas during migration

Most migration bugs come from code that relied on bridge-era behaviour: imperative calls into native views, timing assumptions about layout, unmaintained native libraries, and build configuration left behind by years of manual edits.

• Imperative native calls: code that reached into views directly through old UIManager-style APIs needs rewriting; DevTools warnings in 0.80 and later point to many of these.
• Layout timing: screens that measured views after render may behave differently with Fabric; test animations, keyboards and lists.
• Build files: hand-edited Podfiles, Gradle scripts and AppDelegate files are the slowest part of a jump across many versions.
• Node and toolchain: 0.84 needs Node.js 22.11 or later; update CI images as well as laptops.
• Hermes V1: default from 0.84, with no migration needed if you already use Hermes; check any code that depended on JavaScriptCore.

React Native upgrade cost and timeline

For planning, a simple app with few native dependencies usually takes 2 to 4 weeks, a mid-size business app 4 to 8 weeks, and a large app with custom native modules and views 8 to 16 weeks including regression testing.

App profile	Typical timeline	Indicative budget (India-based team)
Under 30 screens, standard libraries, no custom native code	2-4 weeks	₹2.5 lakh to ₹6 lakh (about $3,000 to $7,000)
30-80 screens, payments, maps, push, a few native modules	4-8 weeks	₹7 lakh to ₹16 lakh (about $8,000 to $19,000)
Large app, custom native views, several vendor SDKs	8-16 weeks	₹17 lakh to ₹38 lakh and above (about $20,000 to $45,000+)

These bands include the dependency audit, the version upgrades, native module rewrites, regression testing on real devices and a staged store release. They exclude new features, which we quote separately so the migration scope stays fixed.

Budgets depend mostly on the library audit and how far behind the app is. An app on 0.6x needs more build-file work than one on 0.7x. Teams in the US, UK or Australia comparing in-house and offshore costs can see developer rates in the US, UK and Australia versus India.

What we have learned migrating React Native apps

From our React Native work since 2018, including apps for clients in India, the Gulf and the UK, the deciding factor has rarely been the app's size; it is the number of native dependencies nobody has touched in years.

Patterns from recent anonymised projects:

• A UK field-inspection app on an old 0.6x release had 41 dependencies with native code. Eleven had no New Architecture support; replacing those took more time than the version jumps.
• A Rajkot-based distributor's ordering app had one custom barcode module written in Java. Rewriting it as a TurboModule took four days and made scanning noticeably faster.
• A Gulf retail loyalty app used a payment SDK whose React Native wrapper lagged behind; we isolated it behind a small native module so the vendor update could drop in later.

How to decide: migrate, rebuild or switch framework

Migrate when the business logic is sound and the codebase reasonably tidy; consider a rebuild only when the app is badly structured and due for a redesign anyway, because rebuilds cost more.

A practical test: if more than half the screens are scheduled for redesign in the next year and the state management is tangled, a phased rebuild on the current React Native release can make sense, screen by screen behind the same navigation shell. If most screens are stable and only the plumbing is old, migration is cheaper and keeps users on the same app listing, reviews and package name.

Switching to another cross-platform framework is rarely justified by the migration alone. If you are weighing it anyway, read Flutter vs React Native in 2026 first. If your app is distributed outside Google Play, also check Android developer verification, which adds identity and package registration to Android distribution.

Related reading and next step

These pages cover the related decisions teams face during an upgrade, from framework choice and Android distribution rules to hiring help for the migration itself and the wider mobile roadmap:

• Mobile app development services
• Flutter vs React Native in 2026
• Hire developers in India
• Android developer verification for app owners

Share your package.json and we will send a dependency audit and a fixed quote; reach us through the contact page or WhatsApp.