Under the old architecture, calling `NativeModules.AuthModule.isAuthorized(cb)` works like this, in the example the post itself uses: the arguments are serialized, the message goes over the bridge to a native thread that lives in total isolation from yours, and your callback comes back later [3][15]. Under bridgeless mode the same intent resolves to a C++ host object that the JavaScript engine holds a direct reference to, and the method is invoked directly, with no JSON serialization and no message queue [2][4].
This is a change to the call contract itself, not a faster version of the same call. The author is explicit that the migration means leaving `RCTBridge` behind entirely, and that this is destructive for many legacy libraries [9]. The failure you are budgeting for is a call that has nowhere to land at the moment it is made, not a slow path.
The timing makes this worse than a build-time problem. TurboModules are lazy-loaded, where the old architecture initialized every native module at startup whether or not the user reached that screen [10]. Startup no longer touches the camera or file picker if nobody opens Settings [10]. The same property means a dependency with no TurboModule backing can sit quiet through install, launch, and your happy-path smoke test, and surface on the screen that first reaches it. Two of the three bridge failure modes the author lists are answered by the direct-call path; the third, fixed initialization cost at startup, is answered by lazy loading [16].
Meta's interop shim is what makes a staged migration possible at all: legacy modules run in a bridgeless environment, but the author calls it a stopgap and says the real gains require rewriting modules as TurboModules with C++ Codegen [12]. Interop layers tend to outlive the deadline that justified them. The useful consequence is that the audit unit is one row per dependency, with one column: does this library reach native code through a codegen-backed TurboModule, or is it riding the shim. For the SDKs the author's own team depended on, wearables and medical devices built for the legacy bridge, that column is not something the app team can fill in by writing code [14].
Now the part where the claims are someone else's workload. This post argues from mechanism and from one HealthTech app: HIPAA-aligned RAG pipelines, wearable integrations, FHIR/HL7 data visualizations, a team that went from zero to 21 engineers in 13 months [13]. Fabric's claim is that layout calculation and view update can happen on the same thread without a bridge round-trip [8]. For that to show up as smoother frames in your app, your dropped frames have to trace to per-interaction cross-thread traffic, which is the failure mode the author describes as jumpy headers and white screens during rapid scrolling [6]. If your janky list is waiting on a network response, or on JavaScript doing too much work between frames, then removing serialization has nothing to do with your problem, because that was never the cost you were paying [5].
In my context I would ship on the interop layer and treat per-dependency codegen status as a tracked line item, because the rewrite schedule belongs to vendors rather than to me [12][14].
