Fabric renderer compatibility boundary: React Native New Architecture transition with legacy native modules

Question

In React Native versions that support the New Architecture, the transition from the legacy JSON bridge to JSI changes how JavaScript communicates with native code. Fabric enables synchronous rendering, while TurboModules allow lazy loading of native modules. Teams activating this via the newArchEnabled flag in android/gradle.properties face a compatibility boundary when third-party libraries have not yet migrated to Fabric. The Interop Layer is designed to bridge that gap, but its practical limits remain an unresolved decision for projects in phased migration.

Enabling the New Architecture also alters memory management expectations because C++ host objects are exposed directly through JSI rather than serialized over an asynchronous bridge. Build times typically increase due to CMake or NDK compilation. These shifts create uncertainty about whether a mixed ecosystem—combining bridge-based modules and TurboModules—can be treated as stable without introducing leaks or layout inconsistencies.

What criteria determine whether a legacy native module is safe to use through the Interop Layer under Fabric? How can teams evaluate the memory overhead of JSI host objects before fully committing to the New Architecture? Is there a documented compatibility boundary for mixing TurboModules and bridge-based modules in the same release?

Tasadduq Burney · Answer

Compatibility Criteria for Legacy Modules
A legacy native module is generally safe to use through the Interop Layer if it adheres to the following criteria:

No Direct View Manipulation: The module must not attempt to manually mutate the native view hierarchy using legacy UIKit or Android View methods that bypass the Fabric shadow tree.
  Asynchronous Communication: Modules that rely on the standard RCTBridgeModule or ReactContextBaseJavaModule patterns for data exchange are compatible, as the Interop Layer wraps these to appear as TurboModules.
  Standard Lifecycle Hooks: The module should not rely on internal bridge-specific timing that assumes a strictly asynchronous JSON serialization delay for critical logic.

Evaluating JSI Memory Overhead
Transitioning to the New Architecture replaces JSON serialization with JSI (JavaScript Interface) HostObjects. Because these C++ objects are managed by the JavaScript garbage collector (GC), memory pressure shifts from the bridge queue to the C++ heap.
To evaluate overhead before a full commit, use these verification steps:

Monitor C++ Heap: Use Xcode Instruments (Leaks/Allocations) on iOS or Android Studio Memory Profiler on Android. Look specifically for growth in native memory that does not correlate with JS heap growth.
  Stress Test HostObject Creation: Create a loop that instantiates legacy modules via the Interop Layer and monitor if the native memory is reclaimed after the JS objects are nullified and GC is triggered.
  Baseline Comparison: Compare the resident set size (RSS) of the application with newArchEnabled=false versus true while performing the same set of native module calls.

The Compatibility Boundary
There is no single "hard" documented boundary, but rather a functional coexistence model. The New Architecture maintains a compatibility bridge that allows TurboModules and legacy bridge-based modules to operate in the same release.
Confirmed Behaviors:

Coexistence: You can ship a release where some modules are fully migrated to TurboModules while others remain legacy modules wrapped by the Interop Layer.
  Execution: TurboModules provide synchronous execution via JSI, while Interop-wrapped legacy modules still execute via the underlying bridge mechanism, though they are accessed through a TurboModule-like interface.

Assumptions and Uncertainties
This guidance assumes usage of React Native versions where the Interop Layer is stable (typically 0.7x+). It is uncertain whether certain highly complex third-party libraries that implement their own custom C++ JSI bindings will conflict with the Interop Layer's wrapping mechanism. Teams should verify the generated C++ glue code during the build process to ensure the Interop wrappers are correctly applied.

Missing Diagnostic: To provide a more specific risk assessment, are any of your legacy modules implementing custom UIManager modules or direct native view manipulation?

Fabric renderer compatibility boundary: React Native New Architecture transition with legacy native modules

1 answer

Compatibility Criteria for Legacy Modules

Evaluating JSI Memory Overhead

The Compatibility Boundary

Assumptions and Uncertainties

Your perspective belongs here.

0 question comments