New Architecture default vs legacy opt-out when third-party native modules lack Fabric support

Migration decision at upgrade time

React Native 0.76 enables the New Architecture by default with a documented opt-out via newArchEnabled=false. The legacy architecture is deprecated and slated for removal, so staying on it only delays the inevitable. However, the interop layer that bridges legacy native modules under Fabric has partial, version-dependent coverage.

The concrete constraint is third-party native library compatibility. One unsupported module — whether a camera SDK, Bluetooth wrapper, or custom native view — can force the opt-out for the entire app. Engine choice couples to this decision: Hermes became default in the 0.70 era, and some older libraries still assume JavaScriptCore.

Trade-off to resolve

Accepting the default means testing every native dependency against Fabric and bridgeless initialization now. Opting out buys one more release cycle but adds technical debt and defers the same audit. The Upgrade Helper shows the diff, but it cannot predict runtime interop failures for your specific module set.

Which approach minimizes total migration effort for an app with five to ten third-party native dependencies of mixed maintenance status? Should the audit prioritize libraries with active Fabric ports, or is a staged opt-out with a fixed deadline safer? How do you verify interop coverage beyond a successful build?