The New Architecture: Fabric, TurboModules, and JSI

The bridge/JSI lesson covered how JS and native code have historically communicated, and introduced JSI as the newer, more direct mechanism. The New Architecture is what gets built on top of that newer mechanism: a real, ongoing shift in how React Native renders views and calls native code, described here as the direction the platform is moving in rather than a fully settled, version-pinned fact.

Two pieces, one foundation

The New Architecture is made up of two main systems, both built on JSI instead of the classic asynchronous bridge:

• Fabric — the newer rendering system, responsible for turning your component tree into actual native views. It's built to take advantage of JSI's more direct communication, rather than routing every rendering update through the old bridge's serialized, batched messaging.
• TurboModules — the newer native-module system, replacing how native modules are registered, loaded, and called from JS. Rather than every registered native module being initialized eagerly the moment the app starts (whether or not that session ever uses it), TurboModules supports loading a module lazily, only once something in the app actually calls into it.

Both exist specifically because JSI made a more direct JS-native connection possible; neither would make sense layered on top of the old bridge, which is why this lesson deliberately sits after the bridge/JSI lesson rather than before it.

The practical benefits

Three concrete, real motivations sit behind this shift:

• More direct communication. Instead of every rendering update or native module call being serialized into a message, queued, and processed asynchronously, JSI-based communication can be more direct — in some cases synchronous — cutting out overhead that used to exist on every single crossing between JS and native.
• Lazy-loading native modules. Rather than initializing every native module an app has ever registered at startup, TurboModules can defer that work until a module is actually used, which is a real, meaningful improvement for apps that depend on many native modules but only use a handful in any given session.
• Better type safety at the native boundary, via codegen. The New Architecture leans on generating native-side interface code from a JS/TypeScript specification, so mismatches between what JS expects from a native module and what the native code actually provides are more likely to be caught at build time rather than surfacing as a runtime crash.

Why "current direction," not "finished fact"

This lesson deliberately avoids pinning any of this to a specific version number or claiming the migration is fully complete across the ecosystem. That's not hedging for its own sake — it's the honest state of things: the New Architecture represents where the platform is headed, and where a growing share of apps and libraries already run, but specifics (exact opt-in mechanics, exact compatibility behavior, which libraries have fully migrated) are the kind of detail that shifts release to release. Treat the concepts here — Fabric, TurboModules, JSI as the shared foundation, the performance and lazy-loading motivations — as the durable part, and treat any specific "how do I enable this today" instructions as something to verify against current documentation rather than assume from memory.

What actually changes for you as a developer

This is the part worth being direct about: for the overwhelming majority of application code — components, hooks, state management, styling, business logic — nothing changes at all. A function component returning JSX, a useState call, a StyleSheet.create object all look and behave identically whether the New Architecture is enabled or not. The New Architecture is an implementation detail of how your JS gets turned into native views and how native modules get called — not a change to the programming model you already know from the rest of this track.

The real-world impact falls disproportionately on library authors: a package that ships a native module needs that module to correctly support the new system, and packages that haven't migrated can be a genuine compatibility concern when choosing dependencies for a New Architecture app. For most app developers, the practical skill isn't writing TurboModule code by hand — it's knowing this shift exists, understanding roughly why it matters (performance, lazy loading, type safety), and knowing to check whether a given third-party library supports it before depending on it heavily.

What to remember

• Fabric (rendering) and TurboModules (native modules) are the New Architecture's two main pieces, both built on JSI instead of the old asynchronous bridge.
• Real benefits: more direct JS-native communication, lazy-loading native modules instead of initializing all of them at startup, and better native-boundary type safety via codegen.
• This is described as the platform's current direction, not a fully settled, version-pinned fact — specifics are still evolving.
• Most everyday component code (functions, hooks, styles, logic) doesn't change at all under the New Architecture.
• The real migration burden falls on native-module library authors; as an app developer, the practical skill is knowing this shift exists and checking library compatibility.