How do you plan a React Native upgrade and the move to the New Architecture before an old version blocks your releases?

Sources checked on 12 November 2026.

This guide is for the person responsible for a company app built with React Native (with or without Expo) who has to decide when and how to upgrade it. It describes the order of work, the risks and what to prepare before an estimate.

The short version: the older the version, the more native file and library changes arrive at once. An upgrade does not have to mean rewriting the app, but it needs a dependency inventory, a version path with a checkpoint on 0.81 and tests of the revenue-critical flows.

Three platform changes make postponing the upgrade costly:

• React Native 0.82: no way back to the old architecture.
• Expo SDK 55: New Architecture only, based on React Native 0.83.
• Google Play: a required target API level for new releases from 31 August 2026.

React Native 0.82 is the first version that runs entirely on the New Architecture. According to the React Native 0.82 release announcement, setting newArchEnabled=false on Android and RCT_NEW_ARCH_ENABLED=0 on iOS is ignored in this version.

On the Expo side, the Expo guide to the New Architecture states that SDK 55 and later run only on the new architecture, SDK 55 uses React Native 0.83, and the old architecture was frozen in June 2025: it receives no new features or bug fixes.

The third change concerns the store. Under the Google Play target API level requirements, from 31 August 2026 new apps and app updates must target Android 16 (API 36), with exceptions: Wear OS and Android Automotive OS apps must target at least API 35, and Android TV and Android XR apps at least API 34. Existing apps must target at least API 35 to remain available to new users on newer Android versions.

The scope of an upgrade follows from what is in the project, not from the version number. Before anyone gives a date, collect this information:

The New Architecture status of libraries can be checked on React Native Directory, which marks libraries that work with the new architecture. In Expo projects, the npx expo-doctor command checks dependencies against the data from this site.

The React Native team recommends that projects not yet on the New Architecture first upgrade to 0.81 or Expo SDK 54. These versions contain warnings that help with migration. The plan can look like this:

This split separates two risks: changes caused by the new React Native version and changes caused by the new architecture. When something stops working, it is easier to find the cause. Version 0.81 is only a transitional stage, though: according to the React Native releases page, in November 2026 versions 0.87 and 0.88 are actively supported, and 0.81 is no longer supported.

1. Upgrade to 0.81 or SDK 54 with the old architecture, if the project is on an older version.
2. Enable the New Architecture in the same version and fix the libraries and modules that do not support it.
3. Release and observe the version with the new architecture in users' hands.
4. Upgrade to a currently supported React Native version (in Expo: the latest SDK) once the app runs stably.

A React Native project consists of a JavaScript part, an Android project and an iOS project, so an upgrade touches all three.

In projects without Expo, the Upgrade Helper tool helps by showing the full list of file changes between two selected versions, with comments explaining some of the changes.

In Expo projects, the Expo SDK upgrade walkthrough describes the steps: installing the new expo package version, aligning dependencies with npx expo install --fix and checking with npx expo-doctor. Expo recommends moving one SDK version at a time.

If the project uses Continuous Native Generation, the android and ios directories are generated again, and native changes have to live in configuration and plugins. Manual edits in those directories without such configuration will be overwritten.

For each library or module that does not work with the New Architecture, you have several ways out. The choice depends on how important the feature is and whether the library has active maintainers:

• Update the library to a version that works with the new architecture.
• Replace it with another library of similar scope if the current one is no longer developed.
• Patch it or keep your own fork when the change is small and the library is essential.
• Rewrite your own module as a Turbo Module or a Fabric component.
• Remove the feature if nobody uses it.

If an incompatible third-party library blocks the migration, the React Native team advises contacting its maintainers directly. It is worth doing at the inventory stage, not in the middle of the upgrade.

The new architecture changes how rendering and communication with native code work, so testing should cover how the app behaves on devices, not only whether it compiles. A checklist before release:

• E2E tests of login, purchase, payment and notification flows on Android and iOS.
• Screens with lists, animations and native views on older and newer phones.
• Crash and error reports from a test build before the store release.
• A rollback plan: the previous code ready to ship with a higher version number, and the option to halt a staged release.

Google Play and the App Store let you release a new version in stages (staged rollout on Google Play, phased release on the App Store). This gives time to watch for errors among some users before the version reaches everyone.

An upgrade cannot be timed reliably without an inventory, because two apps on the same version can have completely different dependencies. The scope depends on:

A reliable estimate contains the list of libraries with a decision for each one and a test plan. If an estimate gives only a number of days without such a list, ask for it before work starts.

1. Version distance: how many React Native or Expo SDK releases separate the project from the target.
2. Native libraries: how many need updating, replacing or patching.
3. Your own native code: the number of modules and views to rewrite.
4. Tests: whether automated tests exist or need to be written.
5. Parallel development: whether the team ships new features at the same time.

The inventory may show that the app has more problems than an outdated version: no tests, code without an owner, libraries abandoned by their authors or an architecture that makes every change hard.

Then it is worth comparing an upgrade with modernisation or a rewrite. We describe the criteria for that decision in our guide to repairing, modernising or rewriting a mobile app.

Before talking to a vendor, prepare repository access, a list of business-critical features, the app versions in the stores and whether releases are planned during the upgrade.