React Native, Under the Hood

01 The pieces on the board

Before flows and threads, know the actors. Colors below: JS Platform native C++ core New Arch

02 The threading model

This is the thing to burn into memory — most RN performance intuition comes from knowing which thread does what.

03 The legacy Bridge ≤ the old default

Everything JS ↔ native went over one asynchronous channel. Think of it as a message queue where both sides post batches.

Three "realms" it connected

• NativeModules — JS calling platform APIs (camera, storage, geolocation).
• UIManager — JS describing the view tree; native creating/updating views.
• Events — native sending touches/scrolls back up to JS.

04 Why the bridge had to die

05 JSI — the foundation new arch

JavaScript Interface. A lightweight, general-purpose C++ API that a JS engine implements. It lets native C++ install objects/functions into the JS runtime, and lets JS hold references to and directly invoke C++ — no bridge, no JSON, optionally synchronous.

The two primitives that matter

// Conceptually: install a native-backed object into JS
auto obj = jsi::Object::createFromHostObject(rt, myCppModule);
rt.global().setProperty(rt, "__MyModule", obj);

// JS side — this now calls straight into C++, synchronously:
const ts = global.__MyModule.nowMillis();  // returns a value, no await

• Engine-agnostic: Hermes, JSC, or V8 can all implement JSI — RN is no longer welded to one engine.
• Synchronous by default (you can still make things async when you want).
• Zero-copy-ish: pass jsi::Values instead of stringifying everything.

06 TurboModules — native APIs on JSI new arch

The replacement for legacy NativeModules. Same idea (JS calling platform code) but built on JSI.

You define a spec (a typed interface). Codegen produces a native base class you implement in ObjC/Kotlin/C++. JS gets a JSI-backed proxy that resolves the actual module lazily on first call.

// NativeCalc.ts  — the spec Codegen reads
import {TurboModule, TurboModuleRegistry} from 'react-native';
export interface Spec extends TurboModule {
  add(a: number, b: number): number;   // note: sync return
}
export default TurboModuleRegistry.getEnforcing<Spec>('Calc');

07 Fabric — the renderer new arch

The new rendering system. The big move: the shadow tree and rendering logic live in shared C++, called directly through JSI, instead of being coordinated over the async bridge via UIManager.

Three trees to keep straight

What Fabric buys you

• Concurrent React — Suspense, transitions, startTransition actually work because the renderer supports interruptible/prioritized rendering.
• Synchronous layout & measurement — read layout during render without a bridge round-trip.
• Better view flattening — collapse layout-only views to fewer host views.
• Shared core — one C++ implementation across iOS/Android, less per-platform drift.
• Type-safe props for components via Codegen (component specs).

08 Codegen — the type-safe glue new arch

Both TurboModules and Fabric components need the JS side and native side to agree on exact types. Writing that boilerplate by hand is error-prone, so Codegen generates it at build time from your specs.

09 Bridgeless mode new arch

The New Arch can technically run with the old bridge still present (for interop). Bridgeless removes it entirely — no message queue anywhere. Communication is 100% JSI, and a new RuntimeScheduler handles prioritization/ordering of work that the bridge's batching used to (accidentally) provide.

• Faster, lower-memory startup (no bridge init, lazy modules).
• Native module init and event dispatch go through the new infra (TurboModule registry, event emitters).
• Interop layers let unmigrated legacy modules/components still work while bridgeless — they're shimmed onto the new system.

10 The Fabric render pipeline, end to end

What actually happens between setState and pixels changing.

Events (touch, scroll) flow the other way: native captures them, and through the C++ event system + JSI they're delivered to JS handlers — with priorities via the RuntimeScheduler.

11 Cold-start sequence

• 1. Native launch — OS starts the app; RN host (ReactHost/RCTHost) initializes.
• 2. Load the JS bundle — read index.jsbundle (prod) or fetch from Metro (dev). With Hermes this is precompiled bytecode → no parse cost.
• 3. Init the runtime — create the JS engine + install JSI bindings (TurboModule registry, Fabric UIManager). Bridgeless: no bridge setup.
• 4. Run the bundle — top-level JS executes, AppRegistry.runApplication mounts your root component.
• 5. First render — the pipeline above runs; first frame paints. Native modules load lazily as touched.

12 Hermes — the engine

The default JS engine, purpose-built for RN's constraints (mobile, short-lived, startup-sensitive).

• AOT bytecode — JS is compiled to Hermes bytecode at build time, so the device skips parse/compile on startup.
• No JIT — trades peak throughput for fast startup + low memory, which usually wins on mobile.
• Small footprint — smaller engine, lower TTI, better on low-end Android.
• Implements JSI — which is why it slots into the New Arch cleanly. (JSC/V8 also can.)

13 Old vs New — one-screen cheat sheet