React Native Development: New Architecture, Fabric, TurboModules, and Hermes [2026]

React Native Development: The New Architecture Changes Everything

React Native spent its first six years under a persistent criticism: the JavaScript bridge. Every interaction between the JavaScript runtime and the native platform required serialization through an asynchronous JSON-based bridge, capping throughput, adding latency to animations, and creating a class of performance problems that required significant engineering effort to mitigate.

The New Architecture eliminates the bridge. Fabric (the new renderer), TurboModules (the new native module system), and JSI (the JavaScript Interface) replace the old synchronous/asynchronous bridge with direct C++ function calls. Combined with the Hermes JavaScript engine, React Native 0.73+ applications achieve near-native performance on the workloads that previously required architectural workarounds.

This guide covers the technical mechanics of the New Architecture, the Expo vs. bare workflow decision, development process, state management, and the engineering context that determines whether React Native is the right choice for a given project.

---

React Native Development: The Architecture That Makes It Work

Old Architecture: The Bridge Problem

The original React Native architecture separated JavaScript execution from native rendering across a serialization boundary:

1. React component tree renders in the JavaScript engine
2. Virtual DOM diffing produces a changeset
3. Changeset serializes to JSON
4. JSON crosses the bridge (asynchronous, batched)
5. Native side deserializes and applies changes to UIView/Android View hierarchy

Every animation frame paid this serialization cost. For 60fps animations, the bridge had to complete the serialization-transfer-deserialization cycle in under 16ms — and under load, it often couldn't. This produced the "jank" (frame drops, laggy interactions) that became React Native's reputation problem.

The New Architecture: Fabric + JSI

JSI (JavaScript Interface) is a C++ API layer that allows JavaScript code to hold direct references to C++ objects and call C++ functions synchronously. Instead of serializing to JSON and crossing the bridge:

// Old bridge: serialize → transfer → deserialize → execute
NativeModules.Camera.capturePhoto().then(result => {});

// JSI: direct C++ function call
const image = jsiCamera.capturePhoto(); // synchronous

JSI enables the rest of the New Architecture changes.

Fabric (the new renderer) uses JSI to make the rendering pipeline synchronous when needed. Critical updates (touch response, animation frames) can now run synchronously with JavaScript execution, eliminating the frame drop issues that plagued complex animations in the old architecture.

TurboModules replace the old NativeModules system. TurboModules are lazily loaded (not pre-loaded at startup), reducing app startup time. They use JSI for direct communication with JavaScript, bypassing the bridge entirely.

In production React Native applications using the full New Architecture, startup time improves 20-40% and animation jank is measurably reduced. The performance gap between React Native and Flutter narrows to within measurement noise for typical application workloads.

Hermes: The JavaScript Engine Designed for Mobile

Hermes is Meta's JavaScript engine, purpose-built for mobile constraints. It differs from JavaScriptCore (Apple's engine) in one critical way: bytecode pre-compilation.

Hermes apps ship with pre-compiled bytecode rather than raw JavaScript source. The startup sequence:

• Standard JS: parse source → compile to bytecode → execute
• Hermes: load pre-compiled bytecode → execute (parsing and compilation already done at build time)

Measured impacts:

• App startup time: 20-30% reduction
• Memory usage: 15-20% reduction
• APK/IPA size: 5-10% reduction (Hermes engine is smaller than JavaScriptCore)

Hermes is the default engine in React Native 0.70+ and should always be enabled for production builds.

---

Expo vs. Bare Workflow: Choosing Your Starting Point

Every React Native project starts with a workflow choice that affects infrastructure complexity, native access, and team requirements.

Expo Managed Workflow

Expo's managed workflow abstracts native iOS and Android build infrastructure. Developers write JavaScript/TypeScript; Expo handles Xcode projects, Android Gradle, certificates, and provisioning profiles.

Key capabilities in 2026:

• Expo Router: File-based routing with deep link support out of the box
• EAS Build: Cloud-based iOS and Android builds (no Mac required for Android builds)
• EAS Update: Over-the-air JavaScript bundle updates without App Store/Play Store review
• Expo Dev Client: Custom development build with native dependencies

Expo's managed workflow covers approximately 80% of common mobile app requirements. For the common cases (push notifications, camera, location, payments), Expo provides managed native modules that don't require writing native code.

Choose Expo managed workflow when:

• The application requirements are within Expo's module coverage
• Team has limited iOS/Android native experience
• Rapid iteration and OTA updates are priorities
• Avoiding native build infrastructure complexity is valuable

Bare Workflow (React Native CLI)

Bare workflow gives full access to the iOS (ios/) and Android (android/) project directories. Any native SDK, custom native module, or JSI implementation is possible. The trade-off is native infrastructure ownership: the team manages Xcode projects, Android Gradle configuration, signing certificates, and provisioning profiles.

Choose bare workflow when:

• Custom native modules or JSI bridges are required
• Third-party hardware SDKs (BLE, NFC, enterprise integrations) need direct integration
• React Native is embedded in an existing native app
• Team has iOS/Android native development experience

Expo with local development build is now a valid middle path: start with Expo, add native dependencies via Expo Modules API, and keep the managed infrastructure benefits while accessing custom native code.

---

React Native Development: Project Structure and Architecture

TypeScript as Default

All React Native projects in 2026 should start with TypeScript. The React Native CLI and Expo both scaffold TypeScript by default. Type-safe props, strict null checking, and IDE autocompletion reduce runtime errors and improve refactoring safety.

interface ProductCardProps {
  product: Product;
  onAddToCart: (productId: string) => void;
}

const ProductCard: React.FC<ProductCardProps> = ({ product, onAddToCart }) => {
  return (
    <Pressable onPress={() => onAddToCart(product.id)}>
      <Text>{product.name}</Text>
    </Pressable>
  );
};

TypeScript doesn't prevent runtime errors from native module integration or async state issues, but it eliminates the large class of errors caused by incorrect prop types, missing null checks, and incompatible API shapes.

Navigation: React Navigation

React Navigation is the standard navigation library for React Native. In 2026, React Navigation 6.x with Stack, Tab, and Drawer navigators covers most navigation patterns. Expo Router builds on React Navigation to provide a file-based routing model (similar to Next.js) for projects using the Expo ecosystem.

Deep link configuration differs between iOS (Associated Domains, Universal Links) and Android (Intent Filters), but React Navigation handles the URL-to-screen mapping uniformly once native configuration is complete.

State Management

React Query (TanStack Query): The standard for server state management. Handles caching, background refetching, loading/error states, and optimistic updates for API-backed data. Replaces manual useEffect + useState patterns for data fetching.

Zustand: Lightweight client-side state management. A global store defined with a single function, accessed via hooks. Appropriate for authentication state, UI preferences, cart contents — anything that needs to be shared across the component tree without server synchronization.

Redux: Still used in large enterprise React Native applications, particularly those with complex cross-screen state and existing Redux expertise on the team. Redux Toolkit reduces Redux's setup overhead significantly.

React Context: Appropriate for static or rarely-updated shared state (theme, locale). Avoid for frequently-updated state — Context updates re-render all consumers.

---

Performance Optimization: Practical Patterns

With the New Architecture, the biggest React Native performance issues in 2026 are in the JavaScript layer, not the bridge.

Unnecessary Re-renders

The most common source of React Native performance issues. Every setState call triggers a re-render of the component and all its descendants. Mitigations:

• React.memo(): Wraps a component to skip re-renders when props haven't changed
• useMemo(): Memoizes expensive computed values
• useCallback(): Memoizes callback functions to prevent child component re-renders
• FlatList's keyExtractor and getItemLayout: Enable optimized list rendering

FlatList Optimization

FlatList is React Native's virtualized list component. For lists with many items (50+), proper configuration significantly affects scroll performance:

<FlatList
  data={products}
  keyExtractor={(item) => item.id}
  getItemLayout={(data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  })}
  removeClippedSubviews={true}
  initialNumToRender={10}
  maxToRenderPerBatch={5}
/>

getItemLayout enables instant scroll-to-index without measuring. removeClippedSubviews reduces memory pressure for long lists. initialNumToRender and maxToRenderPerBatch control how many items render on initial load and subsequent batch renders.

Hermes and JS Bundle Size

Keep the JavaScript bundle lean. Tree-shaking, code splitting (dynamic imports), and avoiding large utility libraries (Lodash — import individual functions, not the whole library) reduce bundle size and parse time.

Use the Hermes bundle transformer to pre-compile bytecode: hermes -emit-binary -out output.hbc bundle.js. This runs as part of the standard release build with Hermes enabled.

---

Testing Strategy for React Native

A complete React Native testing stack:

Unit tests (Jest): Business logic, utility functions, custom hooks. React Native Testing Library for component rendering and interaction tests. No native dependencies — runs in Node.js.

Component tests (React Native Testing Library): Render components, simulate user interactions, assert on rendered output. Tests run against a JS-only mock of React Native components — fast and reliable.

End-to-end tests (Detox): Full application flow tests on real devices or emulators. Detox controls the app via native automation APIs, testing real user journeys (login, checkout, form submission). Slow but high-confidence.

Target coverage distribution: 70-80% unit/component, 20-30% integration, 5-10% E2E for critical paths.

---

React Native in Production: Major Deployments

React Native's credibility comes from its production usage at scale:

• Meta: Instagram, Facebook Marketplace, Ads Manager built substantially on React Native
• Shopify: Mobile checkout flow and merchant apps
• Microsoft: Office Mobile (Word, Excel, Teams features)
• Discord: Chat infrastructure components
• Airbnb: Used React Native extensively (later migrated specific high-performance screens to native)

The Airbnb case is instructive: they migrated specific performance-critical screens back to native while keeping React Native for the majority of the app. This pattern — React Native for 80-90% of screens, native for the high-performance subset — is valid and sometimes optimal.

---

OTA Updates: Deployment Without App Store Review

React Native's most operationally powerful capability: JavaScript bundle updates can be shipped without going through App Store or Google Play review.

Expo EAS Update: Expo's OTA update service. A new JavaScript bundle deploys in minutes. Users receive the update on next app launch (or in the background for silent updates).

Nitro (Meta's system): Similar capability, available to teams running bare workflow.

OTA update scope is limited to JavaScript code. Native code changes — new permissions, new native modules, binary changes — still require a store submission. For bug fixes, content updates, and feature flags in the JavaScript layer, OTA update is a significant operational advantage over native or Flutter.

---

FAQ: React Native Development

Is React Native still worth adopting in 2026 vs. Flutter?

Yes, for specific contexts. React Native is the better choice when: the team has strong React production experience, the product needs web/mobile code sharing, native UI conventions per platform matter, or the OTA update capability is operationally important. Flutter is better for raw performance, higher code sharing, and teams without JavaScript mobile experience. Neither dominates — the choice should be driven by team expertise and product requirements.

Does the New Architecture require rewriting existing React Native apps?

No. New Architecture adoption is incremental. Existing apps can migrate component-by-component. Meta gradually migrated large Facebook properties over 2-3 years. The benefit of migration is primarily performance — apps on the Old Architecture still function correctly, they just miss the performance improvements.

What is JSI and why does it matter?

JSI (JavaScript Interface) is the C++ layer that allows JavaScript code to hold references to C++ objects and call C++ methods synchronously. It's the foundation of the New Architecture: Fabric uses JSI to make rendering synchronous, TurboModules use JSI to eliminate serialization overhead. For application developers, JSI is mostly invisible — it's the plumbing that makes Fabric and TurboModules work.

When should I use Expo vs. bare workflow?

Start with Expo. If you hit a requirement that Expo's module system doesn't cover (uncommon), add a local development build or migrate to bare. The vast majority of React Native applications don't need custom native code beyond what Expo's ecosystem provides. Using bare workflow by default for "control" adds native infrastructure complexity without benefit for most projects.

How do OTA updates work for production bug fixes?

EAS Update ships a new JavaScript bundle. Users receive it on next app launch (configurable). The update is scoped to JavaScript changes only — UI changes, business logic fixes, API endpoint changes, feature flags. Native changes (permissions, new native modules) require a store release. OTA is the right tool for rapid iteration on JavaScript-layer issues; store releases are required for anything touching native.

What is Hermes and is it necessary?

Hermes is Meta's mobile-optimized JavaScript engine that ships pre-compiled bytecode. It reduces startup time 20-30% and memory usage 15-20% compared to JavaScriptCore. It's enabled by default in React Native 0.70+ and should remain enabled for all production builds. The only reason to disable it is a third-party library incompatibility, which is increasingly rare as the ecosystem has largely adapted.

---

Conclusion

React Native development in 2026 is defined by the New Architecture transition. Fabric's synchronous rendering, JSI's direct native access, TurboModules' lazy loading, and Hermes' startup performance collectively close the performance gap with native that defined the previous generation of React Native critiques.

The framework's enduring advantage is the JavaScript/React ecosystem: access to npm's library breadth, React's component model, and a developer pool that vastly outnumbers Dart developers. For teams with production React experience, React Native remains the most direct path to a high-quality iOS and Android product.

The architectural decisions that matter most: New Architecture adoption from day one, Hermes enabled for production, TypeScript strict mode, React Query for server state, and Detox for end-to-end testing. Get these foundations right and the framework's capabilities deliver.

---

Related guides:

• Flutter App Development: Dart, Widget Tree, and Platform Channels
• Cross-Platform Mobile Development: Flutter vs React Native vs MAUI
• iOS App Development: Swift, SwiftUI, and App Store Guidelines