Skip to main content

React Native Architecture

React Native architecture has two levels that matter to application teams:

  1. The product architecture you design inside your app.
  2. The runtime architecture React Native uses internally to render, communicate with native code, and execute JavaScript.

You need both. Product architecture keeps the codebase maintainable. Runtime architecture helps you make better choices about performance, interoperability, and library selection.

Architecture layers​

Application layer​

This is your code:

  • Screens and navigation
  • Feature modules
  • State and data orchestration
  • Design system primitives
  • Service wrappers

Most engineering time is spent here.

React Native platform layer​

This is where React Native exposes:

  • Built-in components and APIs
  • The renderer
  • Native module access
  • Platform event handling
  • Bundling and runtime integration

Native host layer​

This is iOS and Android:

  • UIKit / Swift / Objective-C
  • Android Views / Kotlin / Java
  • Platform SDKs
  • App lifecycle
  • Native services and operating system constraints

What app teams should know from the official architecture material​

The official React Native architecture overview describes the internals as a conceptual model aimed primarily at library authors and contributors, but it is still valuable for app teams because it clarifies how rendering and host interoperability work. React Native’s architecture documentation centers on the new architecture, rendering, threading, and bundled Hermes behavior.

The new architecture direction​

React Native’s current direction is the new architecture. The official architecture and release materials emphasize Fabric, the new native module model, and better interoperability with host platforms.

For app teams, that means:

  • Prefer libraries that actively support the new architecture.
  • Avoid assumptions based on older bridge-era behavior.
  • Keep native wrappers clean so upgrades remain tractable.

Application architecture recommendations​

Prefer feature-oriented modules​

Structure features so UI, state, validation, analytics mapping, and API orchestration are easy to reason about together.

Build a platform layer inside the app​

Create shared app-owned modules for:

  • analytics
  • networking
  • auth
  • notifications
  • storage
  • deep links

This gives your team one internal contract even when vendors change.

Keep the native boundary explicit​

Native code should be treated like an integration surface with ownership, versioning, and tests. It should not behave like an undocumented extension point that anyone touches casually.

Architecture questions every team should answer​

  • What belongs in shared UI primitives versus feature modules?
  • Which services are app-wide and which are feature-owned?
  • How are native capabilities exposed to the JavaScript side?
  • Which layers are allowed to import which others?
  • How are cross-cutting concerns such as analytics and permissions enforced consistently?

Outcome​

Good React Native architecture minimizes accidental complexity:

  • product logic stays shared
  • platform specifics stay isolated
  • performance issues are easier to diagnose
  • upgrades are less disruptive

Continue with New Architecture and Runtime for the internal model.