React Native's New Architecture in Production: What JSI, Fabric, and TurboModules Actually Change

React Native's New Architecture — JSI, Fabric, and TurboModules — has been "coming soon" for long enough that some teams wrote it off as vaporware. It shipped. It is now default in new React Native projects. And it meaningfully changes how the framework works at the performance-critical boundaries between JavaScript and native code.

This post is not a getting-started guide. It is an honest account of what the New Architecture actually changes in production applications — which performance improvements are real, which problems it does not fix, what the migration involves, and what you need to know before enabling it on an existing app.

---

What the Old Architecture Got Wrong

To understand what the New Architecture changes, you need to understand what it replaces.

The Old Architecture communicated between JavaScript and native code through a bridge — an asynchronous, serialisation-based message-passing system. JavaScript could not call native code directly. It sent a serialised message (JSON) to the bridge, the bridge deserialised it, passed it to the native thread, native code executed, serialised a response, and sent it back.

This created three fundamental problems.

Asynchronous communication for synchronous needs. Some interactions require synchronous communication between JS and native — reading a layout value to position an animation, for example. With the bridge, this required workarounds that were either slow (async round-trips) or brittle (cached values that could be stale).

Serialisation overhead. Every interaction between JS and native went through JSON serialisation and deserialisation. For high-frequency interactions — scroll events, gesture callbacks, animation frames — this overhead was measurable.

Eager initialisation of all native modules. The Old Architecture initialised every registered native module at startup, regardless of whether it was used. In large applications with many native modules, this contributed significantly to startup time.

---

What JSI Actually Does

JSI — the JavaScript Interface — replaces the bridge with direct JavaScript bindings to C++. JavaScript can hold references to native objects and call native methods directly, synchronously, without serialisation.

The practical effect is that JavaScript can interact with native code with the same directness as calling a JavaScript function. No queuing, no serialisation, no round-trip to the bridge.

// JSI binding example — what JSI enables at the C++ layer
// This is simplified from how TurboModules work internally

class NativeStorageModule : public jsi::HostObject {
public:
    jsi::Value get(jsi::Runtime& runtime, const jsi::PropNameID& name) override {
        // JavaScript calls this directly via JSI
        // No bridge, no serialisation
        if (name.utf8(runtime) == "getItem") {
            return jsi::Function::createFromHostFunction(
                runtime,
                name,
                1, // number of arguments
                [this](jsi::Runtime& rt, const jsi::Value&, const jsi::Value* args, size_t) {
                    auto key = args[0].getString(rt).utf8(rt);
                    return jsi::Value(rt, jsi::String::createFromUtf8(rt, storage_[key]));
                }
            );
        }
        return jsi::Value::undefined();
    }
private:
    std::unordered_map<std::string, std::string> storage_;
};

From JavaScript's perspective, calling a JSI-backed function feels identical to calling a regular JavaScript function — because it effectively is. The native implementation runs synchronously on the JavaScript thread via the JSI host object protocol.

---

TurboModules: What Changes for Native Module Development

TurboModules use JSI to provide direct, type-safe access to native code from JavaScript. They replace the old NativeModules system with two significant improvements: lazy loading and type safety.

Lazy loading. TurboModules are only initialised when first accessed, not at startup. An app that has 30 native modules but uses only 5 of them in any given session initialises only 5. Startup time reflects actual usage rather than the total module count.

Type safety via Codegen. TurboModules are defined in a TypeScript or Flow spec that Codegen uses to generate native interface code automatically. This eliminates the type mismatch bugs that were common in the old system — where you could pass the wrong type from JavaScript to native with no compile-time error, only a runtime crash.

Here is what a TurboModule spec looks like:

// NativeDocumentProcessor.ts — the spec file
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
    processDocument(documentId: string, options: ProcessingOptions): Promise<ProcessingResult>;
    cancelProcessing(jobId: string): void;
    readonly getVersion: () => string;
}

interface ProcessingOptions {
    extractTables: boolean;
    extractImages: boolean;
    language: string;
}

interface ProcessingResult {
    jobId: string;
    status: 'success' | 'error' | 'partial';
    extractedData: Record<string, unknown>;
    processingTimeMs: number;
}

export default TurboModuleRegistry.getEnforcing<Spec>('DocumentProcessor');

Codegen generates the iOS (Objective-C/Swift) and Android (Java/Kotlin) interface code from this spec. The native implementation provides the actual logic; Codegen provides the glue.

---

Fabric: The New Renderer

Fabric is the New Architecture's UI renderer. It replaces the old shadow tree — a background-thread representation of the UI — with a C++ implementation that can run synchronously on the JavaScript thread when needed.

The most significant practical change for application developers is Concurrent Mode. Fabric enables React's concurrent rendering features in React Native:

• Suspense for data fetching — components can suspend while data loads, with a fallback rendered in their place
• useTransition — expensive updates can be deferred without blocking the UI
• Automatic batching — state updates in asynchronous code are batched automatically, reducing re-renders

// Concurrent features now work in React Native with New Architecture
import { useState, useTransition, Suspense } from 'react';

function DocumentList() {
    const [query, setQuery] = useState('');
    const [isPending, startTransition] = useTransition();

    const handleSearch = (text: string) => {
        // Mark the search result update as a transition
        // UI stays responsive while results load
        startTransition(() => {
            setQuery(text);
        });
    };

    return (
        <View>
            <SearchInput onChangeText={handleSearch} />
            {isPending && <ActivityIndicator />}
            <Suspense fallback={<DocumentListSkeleton />}>
                <DocumentResults query={query} />
            </Suspense>
        </View>
    );
}

---

What the Performance Numbers Actually Look Like

The New Architecture performance improvements are real but context-dependent. Here is what we have measured across our own applications:

Startup time. Improvement is most visible in apps with many native modules. Apps with 20+ native modules see 25–40% startup time reduction from lazy TurboModule initialisation. Apps with few native modules see minimal improvement on this metric.

Scroll and animation performance. Frame drop reduction during complex scroll operations is measurable — we have seen drops from ~2% to ~0.3% in list-heavy views. The improvement comes from Fabric's ability to run layout calculations synchronously and its better integration with the native animation system.

Native module call latency. The JSI-based direct call is faster than the bridge for synchronous calls — sub-millisecond versus 5–10ms for bridge serialisation. For async native operations (network calls, disk I/O), the improvement is not visible because the async operation dominates.

Memory usage. Modest improvement from lazy module initialisation. We have seen 10–15% reduction in idle memory in apps with large native module counts.

The headline: the New Architecture delivers real improvements, but the degree of improvement depends heavily on your specific application. Memory-bound apps or apps with complex gesture handling see more dramatic gains than simple content apps.

---

The Migration Reality

Enabling the New Architecture in an existing app is a multi-step process. The biggest variable is third-party library compatibility.

Checking Library Compatibility

Before doing anything else, audit your dependencies:

npx react-native-community/upgrade-support
# Or check the React Native directory for compatibility info

The React Native directory now shows New Architecture compatibility for listed packages. Libraries that use the old NativeModules system need to be updated to TurboModules before they work correctly with the New Architecture enabled.

Enabling New Architecture

Android:

// android/gradle.properties
newArchEnabled=true

iOS:

# In ios directory
RCT_NEW_ARCH_ENABLED=1 bundle exec pod install

The Bridge-Compatible Pattern for Mixed Migration

If you have custom native modules that are not yet migrated to TurboModules, the Bridge compatibility layer allows old and new modules to coexist:

// Accessing a not-yet-migrated module via the compatibility bridge
import { NativeModules } from 'react-native';

// Old style — still works via compatibility bridge
const { LegacyDocumentModule } = NativeModules;

// New style — direct JSI binding
import NativeDocumentProcessor from './NativeDocumentProcessor';

The bridge compatibility layer is a migration tool, not a permanent solution. Native modules should be migrated to TurboModules progressively.

---

Problems the New Architecture Does Not Fix

It is worth being specific about what the New Architecture does not change, because the marketing around it can create inflated expectations.

JavaScript thread performance. JSI removes the bridge overhead, but the JavaScript thread is still single-threaded. Expensive JavaScript computations still block the UI. The New Architecture does not fundamentally change this — it reduces the cost of JS-to-native communication, not the cost of JavaScript execution itself.

Third-party library ecosystem gaps. Many popular libraries have been slow to add New Architecture support. As of mid-2026, most major libraries support it, but you will still encounter edge cases. Always test your specific dependency tree.

Complex gesture handling. Gesture Responder System limitations are not primarily a bridge problem. The Gesture Handler library (now a recommended standard) addresses these, but it requires its own integration separate from New Architecture migration.

Network performance. Network calls go through the native networking stack regardless of architecture. The New Architecture does not make network calls faster.

---

What to Do Right Now

If you are starting a new React Native project: New Architecture is enabled by default in React Native 0.74+. Leave it on. Start with TurboModules for any custom native code you write.

If you have an existing app on React Native 0.71+: audit your third-party dependencies for compatibility, enable New Architecture in a feature branch, and test comprehensively against your specific hardware targets. Start with your most performance-critical screens.

If you are on React Native below 0.71: upgrade first. The New Architecture on old React Native versions is a different, worse experience than on current versions.

For a broader comparison of React Native and Flutter including how AI-assisted development changes the decision, read Lycore's Flutter vs React Native comparison for 2026.

---

Lycore builds production React Native and Flutter applications for businesses building cross-platform mobile products. We architect, develop, and deliver mobile applications that perform reliably on real hardware. Get in touch.