skip to content

Interop & Migration

1 roadmap5 questions

The New Architecture is the only architecture since 0.82, yet old-bridge libraries still load through interop layers. Interviewers ask how you audit dependencies and what breaks on the move.

part ofReact Nativeoverview, primer and where to startread it →
on this pageshow

explore

questions

5

In React Native 0.87, can a team still switch the New Architecture off, and what happens if gradle.properties sets newArchEnabled=false?

level: middleimportance: must knowfreq 62%

answer

  1. default in 0.76, opt-out allowed
  2. frozen in 0.80, warnings in DevTools
  3. 0.81 and Expo SDK 54: last legacy
  4. 0.82: flags ignored, warning logged
  5. 0.84: iOS legacy code compiled out

basics

~20 s

No. The New Architecture is the only architecture since React Native 0.82: newArchEnabled=false on Android and RCT_NEW_ARCH_ENABLED=0 on iOS are ignored with a warning, and the app still runs on it, with old libraries loaded through interop layers.

solid answer

~40 s

The New Architecture became the **default in 0.76**, with an opt-out, and **0.82 made it the only architecture**. Since then `newArchEnabled=false` in `gradle.properties` makes the Gradle plugin log a warning that the setting is not supported since 0.82, and the app still builds and runs on the New Architecture; `RCT_NEW_ARCH_ENABLED=0` at `pod install` prints the same kind of warning on iOS. The last releases that could run the Legacy Architecture were **React Native 0.81 and Expo SDK 54**. Removal of legacy code then began: in **0.84** iOS builds compile Legacy Architecture code out by default and Android lost a batch of legacy classes, with more removed in 0.85. Old-architecture libraries keep working where the **interop layers** cover them, which the team said it would keep for the foreseeable future.

code

bash · 5 lines
bash
# Ignored since React Native 0.82: pods still install the New Architecture
RCT_NEW_ARCH_ENABLED=0 bundle exec pod install

# 0.84+: re-include legacy iOS code only by building React Native from source
RCT_USE_PREBUILT_RNCORE=0 RCT_REMOVE_LEGACY_ARCH=0 bundle exec pod install

go deeper

for a junior

Remember that the New Architecture is the only architecture in current React Native, and that setting newArchEnabled=false no longer turns it off.

for a middle

Lay out the timeline: default in 0.76, frozen in 0.80, last selectable in 0.81, mandatory in 0.82, legacy iOS code compiled out in 0.84, and what each old flag does now.

for a senior

Plan a legacy app's migration through 0.81, where the fallback still exists, and watch for stray opt-out flags that only produce warnings and mislead the team.

for a principal

Treat the architecture as settled platform ground: budget for removing legacy dependencies rather than for keeping a switch that no longer exists.

## The short answer In React Native 0.87 there is no switch. The **New Architecture** (Fabric renderer, Turbo Native Modules, bridgeless runtime) is the only architecture React Native runs. The old opt-out flags are still recognised, but only so that the build can warn you they do nothing. Interviewers ask this because many codebases, blog posts and CI scripts still carry those flags. A candidate who believes they work will misdiagnose upgrade failures, while one who knows the timeline can explain exactly which release took away which option and what replaced it. ## How React Native got here 1. **0.76**: the New Architecture becomes the default. Most apps upgrade like any other release thanks to an **automatic interoperability layer** for old-architecture libraries, and teams can opt out with `newArchEnabled=false` on Android or `RCT_NEW_ARCH_ENABLED=0` when installing pods on iOS. Expo SDK 52 carries this release. 2. **0.80**: the Legacy Architecture is declared **frozen**: no new fixes or features, no more testing of it during releases. React Native DevTools starts showing warnings for APIs that will stop working. 3. **0.81 and Expo SDK 54**: the **last versions that allow the Legacy Architecture**. The 0.82 release post tells teams still on it to migrate here first. 4. **0.82**: the New Architecture becomes the **only** architecture. The opt-out flags are ignored. No legacy APIs are removed yet. 5. **0.83**: an experimental iOS flag, `RCT_REMOVE_LEGACY_ARCH=1`, compiles legacy code out. 6. **0.84**: compiling legacy code out becomes the **iOS default**, and a list of legacy Android classes is removed. 7. **0.85 and 0.86**: further cleanup, such as removing `CatalystInstanceImpl` and deprecating `ViewUtil.getUIManagerType`. ## What the old flags do now | Setting | Where | Behaviour in 0.87 | |---|---|---| | `newArchEnabled=false` | `android/gradle.properties` | Gradle logs that it is "not supported anymore since React Native 0.82"; the app runs on the New Architecture | | `RCT_NEW_ARCH_ENABLED=0` | `pod install` environment | The pods script prints a "NEW ARCH ONLY" warning; the app runs on the New Architecture | | `RCT_REMOVE_LEGACY_ARCH=0` | `pod install` environment | Re-includes legacy iOS code, but only when building React Native from source (`RCT_USE_PREBUILT_RNCORE=0`) | The first two are warnings, not errors that stop the build. That is exactly why they are dangerous in an old project: a team can believe it opted out when it did not. ## What "only architecture" does and does not mean - **It does mean** there is no Paper renderer and no bridge to fall back to at runtime. Every screen renders through Fabric. - **It does not mean** every old library broke. The **interop layers** host legacy view managers inside Fabric and serve legacy native modules to JavaScript. The 0.82 post says they stay "for the foreseeable future". - **It does not mean** every legacy API still works. Interop does not support custom shadow nodes or concurrent features, some Paper-only `UIManager` calls now just log an error, and each release since 0.84 removes more legacy native classes, which breaks libraries that compiled against them. - **It does mean** the escape hatch is gone. A library problem has to be fixed, upgraded, replaced or ported; it cannot be avoided by switching architectures. ## If an app is still on the Legacy Architecture The path the React Native team recommends is incremental: 1. Upgrade to **0.81** (or Expo SDK 54), the last versions that still let you choose. 2. Turn the New Architecture on there and fix whatever breaks, with the legacy option still available while you investigate. 3. Only then upgrade past 0.82, where the choice disappears. Jumping straight from an old legacy release to 0.87 combines the architecture move with every other breaking change from several releases, which makes each failure much harder to attribute. ## Expo projects Expo SDK 57 apps run React Native 0.86, so the same rules apply: the New Architecture is the only architecture. Expo SDK 54 was the last SDK able to run the Legacy Architecture. ## Summary Since 0.82 the New Architecture is not a setting but the platform. The old flags survive only as warnings, the Legacy Architecture's code is being removed release by release, and the interop layers are what keep older libraries running in the meantime.

  • Why does React Native recommend going through 0.81 rather than jumping straight to 0.87 from an old legacy release?
    0.81 (and Expo SDK 54) is the last release where the Legacy Architecture can still be selected. Turning the New Architecture on there isolates architecture problems from the many other breaking changes of later releases, and keeps a fallback while you fix libraries. Past 0.82 the fallback is gone, so every incompatibility blocks the upgrade.
  • Did React Native 0.82 remove the Legacy Architecture's APIs?
    No. 0.82 removed the ability to choose the Legacy Architecture but deliberately removed no legacy APIs, to limit breaking changes. Removal started in 0.84, when iOS began compiling legacy code out by default and Android dropped a list of legacy classes, and continued in later releases.

saying these in an interview costs you the question

  • Setting newArchEnabled=false still switches a 0.87 app to the old architecture
  • React Native 0.82 deleted all Legacy Architecture code in one release
  • Old-architecture libraries stopped working entirely once 0.82 shipped
  • The ignored opt-out flags make the build fail with an error
  • The New Architecture only became the default in React Native 0.82
  • Expo projects can still opt out on SDK 57
open as a page

How do React Native's interop layers let a library written for the old architecture run on the New Architecture, and what can they not provide?

level: middleimportance: should knowfreq 45%

basics

~20 s

Interop layers adapt old-architecture code: legacy native modules are served through NativeModules and legacy view managers are hosted in a Fabric wrapper. They cannot provide custom shadow nodes, concurrent features, synchronous typed calls or codegen type safety.

open as a page

After a React Native upgrade, what symptoms show that a library still relies on legacy-architecture APIs, and how do you trace each symptom to its cause?

level: seniorimportance: should knowfreq 32%

basics

~20 s

Legacy dependence shows as Android compile errors on classes removed in 0.84 or 0.85, iOS build failures now that legacy code is compiled out, 'not available in the new architecture' errors, nil-returning bridge-proxy calls and Unimplemented component placeholders.

open as a page

Before upgrading a React Native ride-hailing app that depends on 40 third-party libraries, how do you audit them for New Architecture compatibility?

level: seniorimportance: should knowfreq 42%

basics

~20 s

Drop pure-JavaScript libraries, check each native one's New Architecture status in React Native Directory, its codegenConfig and release notes, then run every flow on the New Architecture and sort libraries into supported, interop-only, broken or replace.

open as a page

When a third-party library blocks a React Native app's move to the New Architecture, how do you decide whether to replace it, fork it, or port it yourselves?

level: principalimportance: should knowfreq 22%

basics

~20 s

Weigh the feature's importance, a maintained alternative, the native surface and whether the team can own it: replace when a good alternative exists, fork or port when none does and you can maintain it, and treat interop as borrowed time.

open as a page