React Native 0.82: the New Architecture is mandatory, what should you do with your app?
By Nathan Guigui, Founder of GUIGUI Tech · Facts checked against the official sources listed at the end of the article
Since React Native 0.82, released in October 2025, the New Architecture is the only architecture available: the options that used to disable it are ignored. If your app still runs on the legacy architecture, you can no longer upgrade without migrating first. The approach recommended by the React Native team is to go through React Native 0.81 (or Expo SDK 54), enable the New Architecture there, validate everything, and only then upgrade to 0.82 or later.
The information below is up to date as of October 2026.
What changed with React Native 0.82?
React Native 0.82, released on October 8, 2025, is the first version of React Native that runs only on the New Architecture: it is no longer possible to go back to the legacy architecture.
A quick reminder: what is the New Architecture?
The React Native New Architecture is a rewrite of the framework's internal layers, replacing the historical asynchronous "bridge" between JavaScript and native code. It brings together several building blocks:
- Fabric, the new rendering engine, which replaces the old UI Manager;
- TurboModules, the new native module system, loaded on demand and called through JSI rather than through the bridge;
- Codegen, which generates the interface code between JavaScript and native at build time from typed specifications;
- bridgeless mode, which removes the bridge.
According to the official React Native blog, the New Architecture has been enabled by default in new projects since React Native 0.76 (October 23, 2024). Up to 0.81, it was still possible to disable it.
October 2025: 0.82 only runs on the New Architecture
According to the official React Native 0.82 announcement, published on October 8, 2025, 0.82 is the first version that runs entirely on the New Architecture. In practice:
newArchEnabled=falseingradle.properties(Android) is ignored;- installing pods with
RCT_NEW_ARCH_ENABLED=0(iOS) is ignored; - the app starts on the New Architecture regardless.
The announcement contains two reassuring points. First, the interop layers are retained "for the foreseeable future". An interop layer is a compatibility layer that lets a library written for the legacy architecture keep working on the New Architecture. Second, no legacy architecture API is removed in 0.82 itself; their gradual removal is planned for subsequent versions.
On the Expo side: SDK 54 is the last exit
Expo SDK 54 is the last version of Expo that allows the New Architecture to be disabled; Expo SDK 55 and later only run on the New Architecture.
| Version | Legacy architecture |
|---|---|
| Expo SDK 54 (September 2025, React Native 0.81) | Still possible via newArchEnabled: false |
| Expo SDK 55 and later | Not possible, the newArchEnabled option is removed |
According to its changelog, Expo SDK 54 (September 10, 2025) ships with React Native 0.81. The Expo documentation on the New Architecture is explicit: SDK 54 is the last version where the New Architecture can be disabled, and SDK 55 and later run entirely on the New Architecture. If you leave newArchEnabled: false in your configuration, the setting is simply ignored.
Can you stay on the React Native legacy architecture?
Staying on React Native 0.81 or Expo SDK 54 with the legacy architecture is still technically possible, but it amounts to freezing the app while the ecosystem and store requirements move forward:
- Libraries release their new versions for recent React Native versions.
- The stores require recent tooling. According to Apple's published requirements, since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK. According to the Android Developers documentation, since August 31, 2026, Google Play has required new apps and updates to target Android 16 (API 36), with a possible extension until November 1, 2026 on request. A frozen React Native version eventually stops being compatible with these toolchains, and you can then no longer publish an update, not even an urgent fix.
- The cost grows with the delay. The larger the version gap, the more changes the migration has to absorb in one go.
Key point
An app that is already published is not pulled from the stores overnight. The real risk is no longer being able to publish an update when you need one, for example to fix a critical bug.
How do you know if your React Native app is ready for the New Architecture?
To find out whether a React Native app is ready for the New Architecture, take stock of four points: current versions, dependencies, in-house native modules and your safety net (tests, QA, crash monitoring).
1. Your current versions
Note the React Native version, the Expo version if you use it, and the state of the New Architecture.
npx react-native info
# or, for an Expo project
npx expo config --type public | grep -i newArch
If newArchEnabled is set to false in gradle.properties, app.json or app.config.js, the app runs on the legacy architecture.
2. Your dependencies
For an Expo project, expo-doctor checks your dependencies against React Native Directory data and flags packages that are unmaintained or incompatible with the New Architecture.
npx expo-doctor
For a React Native project without Expo, look up each native dependency on React Native Directory, which shows New Architecture compatibility and the date of the last update. Then sort your libraries into three groups: compatible, compatible after an update, and no compatible version (abandoned or lagging behind).
3. Your in-house native modules
List all the native code written for the project: Swift, Objective-C, Kotlin or Java modules, native components, third-party SDKs integrated by hand. This is often where most of the effort lies. A module that works thanks to the interop layer may be enough in the short term, but a rewrite as a TurboModule or Fabric component is more durable.
4. Your safety net
Do you have automated tests, a documented QA script, a crash monitoring tool? Without them, the testing phase will be longer and riskier.
How do you migrate to the New Architecture, step by step?
To migrate a React Native app to the New Architecture, the React Native team recommends first moving to React Native 0.81 or Expo SDK 54, enabling and validating the New Architecture there, and only then upgrading to 0.82.
- Upgrade to React Native 0.81 or Expo SDK 54, keeping the legacy architecture if necessary. If you are starting from far behind, move in increments and stabilize at each step. For Expo, the documentation recommends, for example, moving from SDK 52 to SDK 53 before testing the New Architecture.
- Update dependencies to compatible versions, and replace those that never will be.
- Enable the New Architecture on that version, where rolling back is still possible.
- Test the app thoroughly on iOS and Android: critical flows, complex screens, animations, lists, native modules, notifications, deep links.
- Fix, then publish a New Architecture release on 0.81 / SDK 54 to validate it in real-world conditions.
- Upgrade to 0.82 and beyond (or SDK 55 and beyond). From that point on, the legacy architecture is no longer an option.
To enable the New Architecture on an Expo SDK 54 project, the setting goes in app.json:
{
"expo": {
"newArchEnabled": true
}
}
On a React Native project without Expo, it is newArchEnabled=true in android/gradle.properties and a reinstall of the pods on iOS.
What are the common pitfalls of a migration to the New Architecture?
The three most common pitfalls of a React Native migration to the New Architecture are abandoned libraries, in-house native modules written for the old bridge and subtle behavioral differences in the new rendering engine.
Abandoned libraries
This is the most frequent blocker. An unmaintained library may work thanks to the interop layer, but the Expo documentation points out that this compatibility is not perfect. The options are: find a maintained alternative, fork and adapt the library, or rewrite the feature. If a third-party dependency is blocking you, the React Native team recommends contacting its maintainers.
In-house native modules
Modules written for the old bridge must at the very least be checked, and ideally migrated to TurboModules with typed specifications for Codegen. Custom native components must be adapted to Fabric.
Behavioral differences
The new rendering engine can subtly change some behaviors: layout measurements, the order of certain events, rendering of components that relied on details of the old implementation. In addition, according to the 0.82 announcement, unhandled promise rejections trigger a console.error since that version, which can surface errors that were previously silent. These discrepancies only show up when testing the real app.
How much effort does a migration to the New Architecture take?
The effort of a React Native migration to the New Architecture depends mostly on the version gap and the amount of in-house native code. Here is a qualitative guide:
| Situation | Typical effort |
|---|---|
| Recent Expo app (SDK 52 to 54), few native dependencies | Low: upgrade, enablement, test campaign |
| React Native 0.7x app with a few libraries to replace | Moderate: several version increments, dependency replacement |
| Older app (0.6x or earlier), in-house native modules, abandoned libraries | Significant: treat it as a project in its own right |
| Very old app, heavy technical debt | A rebuild may become more reasonable than a migration |
In the last case, a prior audit lets you decide between migration and rebuild based on concrete evidence rather than gut feeling.
What checklist should you follow to migrate to the New Architecture?
- Note the versions of React Native, Expo, Xcode, Android Gradle Plugin and
targetSdkVersion - Run
npx expo-doctoror check each dependency on React Native Directory - List the libraries with no compatible version and choose a solution for each
- Inventory in-house native modules and components
- Upgrade to React Native 0.81 or Expo SDK 54
- Enable the New Architecture and fix build errors
- Test critical flows on real iOS and Android devices
- Publish a New Architecture release and monitor crashes
- Upgrade to 0.82 and beyond, or SDK 55 and beyond
- Check store compliance: Xcode 26 / iOS 26 SDK and Android 16 (API 36) target
Getting support from GUIGUI Tech
GUIGUI Tech offers an Expo SDK & New Architecture Upgrade starting at €6,500 excl. VAT, and a React Native Migration Audit at €1,500 excl. VAT to assess your app before you commit. Nathan Guigui, the studio's founder, has been working with React Native for more than ten years, including for Galadrim and Genius Station.
Frequently asked questions
Is the New Architecture mandatory in React Native?
Why does newArchEnabled=false no longer work in React Native?
What is the last version of React Native and Expo with the legacy architecture?
Will libraries that are not compatible with the New Architecture stop working?
Can you stay on React Native 0.81 or Expo SDK 54?
How long does a React Native migration to the New Architecture take?
Need help with this?
Expo SDK & New Architecture Upgrade
Your Expo or React Native app is a few versions behind? Upgrade to the latest Expo SDK, switch to the New Architecture and publish to the stores.
Learn more →
Sources
- React Native 0.82 - A New Era, release announcement of October 8, 2025 (official React Native blog)
- React Native 0.76 - New Architecture enabled by default, October 23, 2024 (official React Native blog)
- Using the React Native New Architecture (Expo documentation)
- Expo SDK 54 release notes, September 10, 2025 (Expo changelog)
- Expo SDK 55 release notes (Expo changelog)
- Target API level requirements — Google Play (Android Developers)
- Upcoming requirements for App Store Connect (Apple Developer)
- Directory of libraries and their New Architecture compatibility (React Native Directory)
