New Architecture and Runtime
React Native’s official architecture direction is centered on the new architecture. The important pieces for app teams are not just the names, but what they change in real engineering work.
Key pieces
Fabric
Fabric is the new rendering system. The official documentation explains that it unifies more render logic in C++, improves interoperability with host platforms, and unlocks capabilities that were not possible in the legacy renderer, including better synchronous interaction with host views and support for newer React capabilities.
Practical impact:
- Better alignment between React rendering and host platform rendering.
- More predictable interoperability when embedding React Native with native views.
- A renderer direction that library authors are expected to target.
TurboModules
TurboModules are part of the new native module model. For app teams, the main significance is that native integrations are moving toward a more typed, code-generated, and modern access path.
Practical impact:
- Better long-term compatibility than older hand-rolled bridge assumptions.
- Stronger library expectations around codegen and typed interfaces.
- Cleaner native module design for teams building proprietary integrations.
JSI
JSI enables direct interaction patterns between JavaScript and native-hosted values without relying on the older serialized JSON-style communication model. In practical terms, this reduces some classes of overhead and makes more flexible runtime integrations possible.
Hermes
The official Hermes docs state that React Native ships with Hermes by default and that many apps benefit from improved startup time, lower memory usage, and smaller app size. The bundled Hermes model also means each React Native release is paired with a tested Hermes version.
Practical impact:
- Fewer compatibility surprises between engine and framework versions.
- Better startup-oriented defaults for many applications.
- A more stable default runtime story for teams upgrading React Native.
Why this matters to app teams
Even if you never write a native module, the new architecture affects you through:
- which libraries are safe to adopt
- how future upgrades behave
- performance characteristics of rendering and host interop
- how platform teams design extensions and shared modules
Engineering standards for the new architecture era
- Prefer actively maintained libraries with clear new architecture support.
- Avoid deep dependence on abandoned bridge-era packages.
- Document every custom native integration.
- Keep app-owned wrappers around SDKs so replacements remain feasible.
- Test upgrades with native builds early rather than assuming JavaScript-only validation is enough.
What not to do
- Do not hardcode architectural assumptions from old blog posts and outdated examples.
- Do not introduce custom low-level runtime work unless your team can support it across upgrades.
- Do not assume all performance issues are solved by "using the new architecture".
Team rule
Treat the new architecture as the baseline direction of the ecosystem and make architecture decisions that keep your app compatible with that direction.
Next, understand the rendering, threads, and performance model.