The React Native New Architecture is no longer optional. It became the default in React Native 0.76, the old architecture was frozen in 0.80, and from 0.82 onward React Native runs only on the new one. If your app is still on 0.81 or earlier with the New Architecture switched off, every month you wait makes the upgrade larger and the next store deadline closer.
This guide is for teams who own one of those apps. It explains what changed, gives the version timeline from the official release posts, and sets out the library audit and step-by-step plan we use. If you would rather hand the work over, our React Native app development company team runs these upgrades as part of our iOS app upgrade services and Android app upgrade services.
What the React Native New Architecture changed
Four pieces replaced the old asynchronous bridge. You do not need to understand their internals to migrate, but you do need to know which parts of your code each one touches.
- JSI (JavaScript Interface). JavaScript holds direct references to native objects and calls them without serialising messages to JSON. This is what removed the bridge bottleneck. It affects anything that talks to native code.
- TurboModules. The new native module system. Modules load lazily when first used, and their interface is defined in a typed spec. Every custom native module you wrote for the old architecture needs to be ported or wrapped.
- Fabric. The new renderer. Native UI components (a custom map view, a video player, a chart drawn natively) must be Fabric components. Layout and rendering can now happen synchronously when needed, which helps with things like measuring views before they paint.
- Codegen and bridgeless mode. Codegen generates the native glue from your TypeScript or Flow specs, so mismatched types fail at build time. Bridgeless mode removes the old bridge entirely, so code that reached into bridge internals stops working.
The practical rule: JavaScript-only code is mostly unaffected. Native modules, native UI components and libraries that wrap native SDKs are where the migration work sits.
Version timeline: from opt-in to the only option
Key dates from the React Native and Expo release posts. The current release as of October 2026 is 0.88.
| Release | Date | What changed | What it means for you |
|---|---|---|---|
| React Native 0.70 | July 2022 | Hermes became the default JavaScript engine | Apps still on JavaScriptCore are already off the default path |
| React Native 0.76 | October 2024 | New Architecture on by default and declared production-ready | New projects use it; old apps could still opt out |
| Expo SDK 52 | 12 Nov 2024 | New Architecture enabled by default for new Expo projects | Expo apps followed the same path |
| React Native 0.80 | 12 June 2025 | Legacy Architecture officially frozen; DevTools warns about incompatible APIs | No more fixes for the old path |
| React Native 0.81 / Expo SDK 54 | Between 0.80 and 0.82 | Last versions that allow the Legacy Architecture | Your last safe stop to test with the flag on and off |
| React Native 0.82 | 8 Oct 2025 | Runs entirely on the New Architecture; opt-out flags ignored | No way back from here |
| Expo SDK 55 and later | After SDK 54 | Run entirely on the New Architecture | Same as 0.82 for Expo apps |
| React Native 0.84 | 11 Feb 2026 | Legacy code removed from iOS builds by default; Hermes V1 default; Node.js 22.11+ required | Smaller iOS builds; update CI Node version |
| React Native 0.88 | 19 Oct 2026 | React 19.3.0, no breaking changes | Current target as of October 2026 |
Sources: React Native blog posts for 0.70 (Hermes), 0.76, 0.80, 0.82, 0.84 and 0.88; Expo SDK 52 changelog and Expo New Architecture guide. React Native ships roughly one minor release every two months.
Why waiting no longer works
The old architecture still runs in apps that were built with it. What stopped is maintenance. Since the React Native 0.80 release, the Legacy Architecture gets no bug fixes and is not tested during releases. Library authors are dropping it too, so each dependency update becomes a negotiation.
Meanwhile the platforms keep moving. Since 28 April 2026, App Store uploads must be built with Xcode 26 or later against the iOS 26 SDK. From 31 August 2026, Google Play requires new apps and updates to target Android 16 (API level 36), with an extension available to 1 November 2026. Our guide to Google Play target API level requirements explains that rule. An app pinned to an old React Native version and old libraries eventually cannot meet a requirement like this without the upgrade you have been postponing, and doing it under a store deadline is the most expensive way to do it.
The toolchain moves as well. React Native 0.84 requires Node.js 22.11 or later. Node.js 22 reaches end of life on 30 April 2027, per the official Node.js release schedule. Node.js 24 moved to Maintenance LTS on 20 October 2026, and Node.js 26 is scheduled to enter Active LTS on 28 October 2026, so set CI to one of those two lines.
On 0.82 or later: you are already on the New Architecture; keep upgrading every few releases. On 0.76 to 0.81 with the New Architecture enabled: mostly a version upgrade. On 0.76 to 0.81 with it disabled: fix compatibility on your current version first, then upgrade. Below 0.76: plan a staged project with an audit first; this is the group most likely to need library replacements.
Step one: the library compatibility audit
Most migrations succeed or fail on dependencies, so the audit comes before any version change. List every package in package.json and every native SDK in your Podfile and Gradle files, then sort them into groups.
Tools that help: for Expo projects, npx expo-doctor checks dependencies against React Native Directory data and flags libraries that are unmaintained or incompatible with the New Architecture, according to the Expo New Architecture guide. For bare projects, check each library’s React Native Directory entry and changelog by hand. On 0.80 or later, DevTools also warns about APIs that will not work on the New Architecture, which is a quick way to find calls buried in your own code.
How to classify each dependency
Record each package in a sheet with these columns: name, current version, has native code (yes or no), New Architecture support, last release date, owner, action.
| Dependency type | Typical risk | Usual action |
|---|---|---|
| JavaScript-only package | Low | Update normally; no architecture work |
| Maintained native library with New Architecture support | Low to medium | Upgrade to the supporting version; read its migration notes |
| Native library with no release in a long time | High | Replace with a maintained alternative, or fork and port it |
| Your own native modules | Medium | Port to TurboModules with Codegen specs, or rewrite with the Expo Modules API |
| Your own native UI components | Medium to high | Port to Fabric components; test layout on both platforms |
| Vendor SDK wrapper (payments, KYC, analytics) | Varies | Ask the vendor for their supported version before planning dates |
Treat compatibility layers that let some old modules keep working as a stopgap. Anything that depends on one should be on the replacement list.
Want the audit done for you?
Share read access to your repository under NDA. We reply within one business day and scope an audit that lists every dependency, its risk and the effort to fix it.
React Native New Architecture migration: step by step
The sequence we follow to keep the app shippable at every stage.
Record a baseline
Capture crash-free sessions, cold start time on a mid-range Android phone, and key screen timings from the current production build. Add smoke tests for the five to ten flows that make money, using Maestro or Detox. Without a baseline, nobody can prove the upgraded app behaves the same.
Update the toolchain
Move CI to a supported Node.js LTS, Xcode 26 and the Android Gradle and SDK versions the target React Native release expects. Do this on its own branch so toolchain breakages are not mixed up with library breakages.
Stop at 0.81 or Expo SDK 54 first
These are the last versions where the New Architecture can be switched off. Upgrade to them, turn it on and fix what breaks. If a problem is hard to isolate, flip the flag back and compare. This is the most valuable debugging window in the whole project.
Port your own native code
Rewrite custom native modules as TurboModules with typed Codegen specs, or with the Expo Modules API in Expo projects. Port native UI components to Fabric. Replace or fork abandoned libraries identified in the audit.
Cross 0.82 and continue in hops
Once everything works with the New Architecture on, move past 0.82, where it becomes the only option. Continue in small hops using the official upgrade helper diffs, testing at each stop. At 0.84, check behaviour under Hermes V1 and the smaller iOS build.
Release in stages
Ship through TestFlight and Play Console internal testing, then a phased App Store release and a staged Play rollout, watching crash reporting in Sentry or Crashlytics. If you use over-the-air updates, bump the runtime version so no JavaScript bundle reaches a binary it was not built for.
Risks and how to contain them
Subtle UI changes. A new renderer can shift layout, text measurement or touch handling in edge cases. Compare screenshots of key screens before and after on both platforms, and include right-to-left layouts if you support Arabic or Urdu.
Vendor SDKs on their own timeline. A payments or identity vendor may not support your target version yet. Find out in the audit, not in week six, and plan dates around them.
Over-the-air update mismatches. Pushing a JavaScript bundle built for the New Architecture to an old binary can crash it. Runtime versions and update channels prevent this; check they are set before the first upgraded release.
Feature work colliding with the upgrade. Long-running branches are where upgrades go to die. Keep the upgrade in small merges to the main branch, and pause large native feature work until the native layer is ported.
Skills. Porting modules and Fabric components is Swift, Objective-C, Kotlin and some C++ work. If your team is JavaScript-only, bring in someone who has done it before, for example when you hire React Native developers through us, rather than learning on the production app. Automated regression tests make every hop cheaper; our automated app testing company page explains how we set them up.
Upgrade or rebuild?
For most apps, upgrading is cheaper than a rewrite. The case for rebuilding is narrower: a codebase several years behind where most native dependencies are abandoned, a product that has drifted into mostly native features, or a redesign planned anyway. In those cases, price both paths before committing. Our React Native vs native comparison helps decide whether a rebuild should stay on React Native at all, and our legacy app modernization company page covers larger rescues.
React Native New Architecture FAQs
Can I still turn off the New Architecture?
Only on React Native 0.81 or Expo SDK 54 and earlier. From React Native 0.82, the opt-out flags (newArchEnabled=false on Android, RCT_NEW_ARCH_ENABLED=0 on iOS) are ignored, and Expo SDK 55 and later run entirely on the New Architecture. Use 0.81 or SDK 54 as a stop where you can compare behaviour with the flag on and off.
Will my app stop working if I stay on the old architecture?
Installed copies keep running. The problem is shipping updates. The Legacy Architecture has been frozen since React Native 0.80, so it gets no fixes, and libraries are dropping support. Apple and Google raise build and target API requirements every year, and an old React Native version with old libraries eventually cannot meet them.
How long does a New Architecture migration take?
It depends on how far behind you are and how much native code you have. An app already on 0.76 or later with the New Architecture enabled is mostly a version upgrade. An app below 0.76 with custom native modules and abandoned libraries is a staged project. The audit gives a realistic estimate, which is why it comes first.
Do I need to rewrite my JavaScript code?
Mostly no. JavaScript and TypeScript code that uses React Native’s public APIs carries over. The work sits in custom native modules, native UI components, libraries that wrap native SDKs and any code that reached into bridge internals. DevTools on 0.80 and later warns about APIs that will not work, which helps you find those calls.
Does Expo make the migration easier?
Usually. Expo SDK releases bundle tested library versions, npx expo-doctor flags dependencies that are unmaintained or incompatible with the New Architecture, and the Expo Modules API is a simpler way to write native modules. The React Native team recommends Expo for new apps. Bare apps can migrate fine too, with more manual version management.
Get your React Native app onto a supported path
Tell us your current React Native version and main dependencies. We reply within one business day with next steps for an audit and an upgrade plan. See how our React Native app development company team handles upgrades.