The Bridge Is Gone: Migrating a Legacy React Native App to 0.85 When New Architecture Is the Only Option

As of React Native 0.85 (released 7 April 2026), the legacy bridge is fully removed. There is no newArchEnabled=false escape hatch anymore. If your app is stuck on a 0.7x release running the old Paper renderer, upgrading past 0.85 means committing to the New Architecture (Fabric + TurboModules + the JSI), and every native module you depend on has to support it or your app crashes on launch. In my app-rescue work, the migration is real but scopeable: the cost is almost never the React Native bump itself, it is the long tail of dependencies that were never rewritten for the new renderer.

Below is the audit, the libraries I see crash most often, and an honest read on effort and cost for rescuing a 0.7x Paper app.

What actually changed in React Native 0.85?

The short answer: the bridge is gone, so the New Architecture is no longer opt-in, it is the only architecture. Before this, even when New Arch was the default, you could set a flag and fall back to the old bridge-based Paper renderer to buy time. That flag no longer does anything in 0.85.

The bridge was the asynchronous, JSON-serialized message channel between JavaScript and native code. Everything went through it: every native module call, every UI update, every event. The New Architecture replaces it with three pieces:

• JSI (JavaScript Interface), a C++ layer that lets JS hold direct references to native objects and call them synchronously, with no serialization.


• TurboModules, native modules built on JSI that load lazily and expose a typed interface.


• Fabric, the new rendering system that replaces Paper and renders the UI through C++ shadow nodes.

Do I have to migrate, or can I stay on 0.7x?

You can stay on 0.7x, but only as a frozen, end-of-life decision, not a strategy. The moment you need a security patch, a new OS SDK, or a library version that dropped old RN support, you are forced forward.

This is the trap I see most. A 0.7x app keeps running for a while, then a real-world deadline lands on top of it. The two I am dealing with most right now:

• Google Play's target API 36 (Android 16) requirement, which makes old apps unsubmittable past the deadline. I wrote about that in the Target API 36 migration checklist ↗.


• The 16 KB memory page size requirement on newer Android devices, which surfaces as a Play Console warning and native crashes. See fixing the 16 KB page size error ↗.

How do I audit my dependencies before migrating?

Start with the React Native Directory and a hard list of every native dependency you ship. The directory tracks a New Architecture support flag per library, and that flag is the single best signal for whether a package will survive the cutover.

My process is the same every time. First, get the real dependency list, not what package.json claims is installed.

## List every package that ships native code
npx react-native config | grep -i "platforms"

## Or inspect what actually has native modules
ls node_modules/*/android/build.gradle 2>/dev/null
ls node_modules/*/*.podspec 2>/dev/null

Then run the upgrade tooling and the dependency check together:

## Align core deps and surface the diff for your version jump
npx @react-native-community/cli@latest doctor

## Check each native dep against the Directory's New Arch flag
npx react-native-community/directory check

For each native package, I record three things in a spreadsheet: does it support New Architecture, what is the minimum version that does, and is that version a major bump with its own breaking changes. That third column is where the hidden cost lives. Upgrading a library to its New Arch release often means jumping two majors and inheriting unrelated API changes.

A pure-JS library (no android/ or ios/ folder, no .podspec) is almost always fine. It never touched the bridge, so it does not care that the bridge is gone. Your risk is concentrated in the native modules.

Which libraries still crash on the New Architecture?

The reliable troublemakers are unmaintained native modules, anything doing custom native UI, and a few popular packages that needed a full rewrite to support Fabric. The pattern is consistent: the more a library reaches into native rendering or threading, the harder its migration was, and the more likely an old pinned version crashes.

Here is how I categorize what I find in an audit.

## Generates the precise diff between two RN versions
## for every template file (gradle, podfile, MainApplication, etc.)
npx @react-native-community/cli upgrade

## android/gradle.properties
## In 0.85 this is effectively the only mode; setting it false no longer
## restores the bridge. Keep it on and treat any "false" comments as dead.
newArchEnabled=true

## ios/Podfile -- New Arch is wired through codegen automatically.
## A clean reinstall after the bump clears most stale native state:
## bundle exec pod deintegrate && bundle exec pod install

The biggest budget mistake I see is scoping the React Native bump and forgetting the testing tail. After the cutover, every screen that touches a native module needs to be exercised on real devices, because a Fabric rendering difference or a TurboModule init failure does not always show up in the simulator. I treat device QA as its own line item, not a rounding error.

This is exactly the kind of work my app rescue and optimization service ↗ exists for: take a 0.7x app that can no longer ship, audit it against the Directory, give you a fixed scope by dependency risk, and bring it across the no-bridge line with a tested build at the end.

The honest takeaway

React Native 0.85 removing the bridge did not break your app, it removed the place you were hiding from a migration you already owed. The framework upgrade is mechanical. The work and the cost live entirely in your dependency graph: which native modules made the jump, which are abandoned, and how much of your own code reaches into native rendering.

Run the audit first. The Directory flag and your native dependency list will tell you within an hour whether this is a five-day job or a five-week one. If you want a second set of eyes on the audit or a fixed scope before you commit, my contact page ↗ is the place to start, and I am happy to look at the dependency list before you write a line of upgrade code.