Preparing Your App for the Post-0.82 World: A New Architecture Migration Checklist

Old-architecture support ended with React Native 0.82: the interop layer and the legacy bridge are gone from current releases. If your app still runs the old architecture, this is the checklist we use to migrate client apps — in order.

1. Turn it on in a branch

For Expo apps, New Architecture is on by default on current SDKs. For bare apps, enable newArchEnabled (both platforms) in a dedicated branch and build. Your goal at this stage is a list of what breaks, not a fix.

2. Audit your dependencies

Run your dependency list against React Native Directory — it tracks New Architecture compatibility per library. Sort the results into:

• Compatible — usually just needs a version bump.
• Compatible via successor — the library was abandoned but has a maintained replacement; swap it.
• Incompatible, no successor — your real migration work. Each of these is either vendored-and-patched, rewritten, or dropped.

The dependencies frozen before 2024 are where migrations actually stall. Count them before you promise a date.

3. Convert your own native modules

Hand-written bridge modules become Turbo Modules: define a typed spec (TypeScript), run codegen, and implement the generated interface. The old pattern —

import { NativeModules } from "react-native";
NativeModules.MyModule.doThing();

— becomes a typed spec the native side implements, with codegen enforcing that JS and native agree at build time. Custom native views make the equivalent move to Fabric components.

While converting, hunt down and remove:

• findNodeHandle / direct UIManager calls
• RCTEventEmitter bridge-event patterns (Turbo Modules emit typed events)
• Anything reading ReactContext off the main queue that assumed bridge threading

4. Fix rendering differences

Fabric is stricter than the old renderer. The usual suspects: layout that depended on undocumented measurement timing, onLayout ordering assumptions, and views mutated outside of React's knowledge. Snapshot-test your critical screens before and after.

5. Measure, then roll out

Measure startup time and list-scroll performance before and after — bridgeless mode and Fabric usually win, and the numbers justify the project to stakeholders. Roll out with a staged release and your crash reporter watched closely for native crashes from converted modules.

How long does this take?

A small app with healthy dependencies: days. A five-year-old app with a dozen native modules and abandoned dependencies: weeks — mostly in step 2's third bucket. If that is where you are, our New Architecture migration service exists precisely for it.