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

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?