React Native's New Architecture, built around Fabric for rendering and TurboModules for native module access, has been available as an opt-in for a while now, with broader adoption clearly coming as the ecosystem catches up. We enabled it on a lower-risk internal app to get ahead of the eventual migration everyone building on React Native will need to make, rather than waiting until it becomes mandatory and dealing with the transition under time pressure.
A couple of third-party native modules needed updated versions before they'd work under the new architecture; TurboModules changes how native code is invoked from JavaScript, and modules built against the old bridge architecture without an update path simply don't function correctly until their maintainers ship compatible releases. We hit this with a barcode scanning library and a native storage wrapper, both of which had community-maintained compatibility patches available, but neither had an officially blessed stable release yet, which is the honest state of the ecosystem at this point in the rollout.
The app itself ran noticeably smoother on complex list views once enabled, which was the most concrete, user-visible benefit. Fabric's rendering pipeline removes a layer of asynchronous bridging between JavaScript and native views that the old architecture relied on, and the difference showed up clearest in scroll performance on screens with a lot of dynamically updating list items, exactly the kind of view where the old bridge's overhead was most noticeable to begin with.
Debugging under the new architecture took some adjustment, since a couple of existing debugging tools and error messages the team was used to from the old bridge don't map cleanly onto Fabric and TurboModules yet, and we occasionally fell back to more manual logging than we'd normally need to track down an issue during the first couple of weeks.
Worth testing early rather than waiting for it to become mandatory, especially for teams with any custom native modules or third-party dependencies with native code, since finding compatibility gaps now, on a lower-stakes internal app, is a much better position than discovering them on a production app under a hard migration deadline later. For teams with a native-module-light app, the migration is likely to be close to a non-event; the risk concentrates almost entirely in whatever native dependencies you're carrying.
Memory usage under the new architecture was another area we tracked closely, since Fabric's more direct native-to-JavaScript communication model changes some of the assumptions our existing performance monitoring had been tuned around. We didn't see a meaningful regression, but the metrics we'd normally watch shifted slightly enough in their baseline values that we had to recalibrate a couple of alert thresholds rather than trust the old ones blindly, a small operational detail that's easy to overlook when focused on the more visible rendering performance story.
We're rolling the New Architecture out to a second, slightly higher-traffic internal app next, specifically chosen because it exercises a different set of native modules than the first pilot did, before considering it for any client-facing production app. Given how actively this part of the React Native ecosystem is still evolving, we'd rather find the next round of compatibility surprises ourselves on low-stakes internal tooling than have a client's production app be where we discover them.