React Native New Architecture Performance Compared to SwiftUI

React Native's New Architecture, enabled by default as of late 2024 and mandatory as of RN 0.82, closes a meaningful chunk of the performance gap that used to separate it from SwiftUI on iOS. It does not close all of it. What follows is a look at exactly which parts of that gap are gone, which parts remain, and why the remainder is a matter of physics rather than tuning.

For years, the case against React Native on performance-sensitive iOS work rested on one design decision: JavaScript and native code lived in separate worlds, and everything passing between them got serialized to a JSON string. That bridge model wasn't a bug someone forgot to fix. It was the foundation the whole framework sat on, and it came with consequences that showed up directly in product quality. Synchronous calls were impossible, full stop, even for operations that felt instant to a user. Passing a large object across the bridge meant running it through JSON.stringify, which could freeze the UI while it worked. Every piece of data got duplicated, once in the JS heap and once in the native heap, which meant memory bloat baked into the architecture itself. And because layout math lived in JavaScript while measurements couldn't be read synchronously, users saw intermediate visual states: things rendering in the wrong place for a frame before snapping into position.

None of that was fixable with better code. It was a structural ceiling, which is exactly why Meta didn't patch the bridge, it replaced it. SwiftUI, and native Swift more broadly, never had these constraints to begin with. Swift compiles straight to machine code. There's no inter-process serialization step, no second heap to sync, and layout and measurement have always been synchronous operations. That gap between the two platforms was real and it was large. The question worth asking now: how much of it has the New Architecture actually closed?

What the New Architecture actually replaced and what it introduced

The centerpiece is JSI, the JavaScript Interface. Instead of JS and native code talking through serialized messages, JS now holds a direct reference to a C++ object and vice versa. That one change removes JSON serialization from the equation and makes synchronous cross-thread calls possible for the first time.

Sitting alongside JSI is Fabric, the new renderer. Fabric moves the layout tree, what React Native calls the shadow tree, out of JavaScript and into C++, while the React reconciler itself keeps running in JS. Because layout now lives in C++, layout reads can happen synchronously. useLayoutEffect finally does what its name always promised: measure and apply in a single commit, with no visual jump between frames. Fabric also opens the door to concurrent rendering, so React 18 features like Suspense, Transitions, and automatic batching now work in native mobile UI the same way they work on the web.

TurboModules replace the old native module system. Native modules load lazily through JSI, synchronous calls are available whenever the app needs them, and Codegen makes the whole thing type-safe by generating C++, Objective-C, and Java bindings straight from TypeScript or Flow definitions at build time. That means fewer runtime type errors and no more hand-written glue code sitting between the two languages.

Then there's Bridgeless Mode, rolled out progressively and now the default (as of RN 0.76, it's universal). Bridgeless Mode strips out even the backward-compatibility shim that used to sit around the old bridge, so the remaining backward-compatibility shim is removed, so the system routes through JSI directly rather than through a legacy compatibility layer.

One more piece worth naming: Hermes is no longer a recommendation, it's a hard requirement. As of RN 0.76, Hermes is a hard requirement in the New Architecture, even though JSI itself is technically engine-agnostic. Hermes brings faster startup and lower memory use than JavaScriptCore, which matters more now that the whole architecture leans on it.

What none of this does is turn React Native into a compiled language. The JavaScript runtime is still there, JS logic and native rendering are still two distinct layers, and the framework hasn't stopped being a cross-language system. It's just a much thinner, faster bridge between those two layers than it used to be.

The rollout timeline engineers need to know before making an architectural decision today

RN 0.76, shipped October 2024, turned the New Architecture on by default. Not experimental, not opt-in behind a flag, just on.

RN 0.80 froze the Legacy Architecture and started surfacing migration warnings, alongside an update to React 19.1.0, a Strict TypeScript API, and gains in both build time and APK size. RN 0.81, paired with Expo SDK 54, is the last version where teams can still disable the New Architecture and fall back to the old one, though the interop layer that eases the transition sticks around in later releases too. RN 0.82 removes that option entirely: the Old Architecture is permanently disabled, and any app running a current framework version has to be on the New Architecture, no exceptions.

Looking further out, RN 0.86, expected June 2026, advances the bridgeless rollout further for new projects. RN 0.87 makes the Strict TypeScript API (generating types from source via Codegen) the default rather than an opt-in setting. On the Expo side, SDK 52, from November 2024, already turned the New Architecture on by default, and most existing Expo apps can adopt it with a single config change.

The bigger open question for any team making a decision today is the library ecosystem, not the framework itself. As of May 2024, 60% of the top 400 most popular React Native libraries had already migrated to New Architecture support. By 2026, that figure sits around 85% of popular npm packages. The remaining 15% are either Bridge-only or partially supported, and that 15% functions as a practical ceiling on adoption: an app that depends on even one of those packages inherits the old bridge's constraints regardless of how far along its own migration is.

Where the performance gap between React Native New Architecture and SwiftUI has measurably closed

Start with the UI thread. Typical apps see somewhere between a 10% and 30% improvement, and apps leaning heavily on native modules see cross-thread call performance improve by up to 3x. That's not a marginal gain, that's the difference between a feature being viable and not.

Animation and gesture handling at high fidelity often relied on react-native-reanimated to offload work and avoid the latency the bridge introduced in real-time interaction. With Fabric, the view system interaction happens more directly and in real time, reducing the overhead that once made such workarounds necessary. The result is a simpler dependency tree and responsiveness that behaves like native code, not like a JS layer straining to keep pace.

Synchronous layout reads matter more than they sound like they should. Tooltip positioning, dynamic sizing, anything following a measure-then-render pattern used to cause a visible jump because the measurement and the render happened in separate passes. This now resolves in a single commit, which removes a whole category of visual glitching that engineers used to just accept as a cost of doing business on this framework.

Cold start numbers tell a similar story relative to other cross-platform frameworks. Flutter starts around 250ms, React Native's New Architecture lands around 350ms. That's a real gap, but it's small enough now that most users won't perceive it. There's no equivalent sourced figure comparing cold start against SwiftUI directly, so that comparison stays open.

And on concurrent rendering: React 18's Suspense, Transitions, and automatic batching are now available natively on mobile, which means patterns web React engineers already know cold behave the same way on a phone. Put plainly, the classes of interaction that used to be flatly off-limits in React Native, like real-time gesture tracking, synchronous measurement, concurrent UI updates, are now achievable without the elaborate workarounds engineers used to build just to fake native-level responsiveness.

Where SwiftUI still leads and why the remaining delta is structural, not fixable by tuning

Under real stress, the gap reopens. A 2025 benchmark found a React Native app dropped 15.5% of frames during a heavy scroll test, while the equivalent native Swift app dropped only 1.6%. That's not a rounding error, that's close to a 10x difference at the exact moment performance matters most.

A separate 2024 study reported SwiftUI averaging around 50ms per transaction against React Native's roughly 70ms, putting SwiftUI about 30% faster (this figure is worth verifying against its primary source independently before treating it as settled). Either way, the direction is consistent: native still wins under load, and it isn't close.

The reason isn't mysterious. Swift compiles directly to machine code. There's no JS runtime sitting in the execution path, no JSI hop, no C++ bridge layer, however thin that layer has gotten. The New Architecture reduces serialization overhead dramatically, but it does not, and structurally cannot, remove the JavaScript execution layer itself. That layer is the entire reason React Native exists as a cross-platform tool, so removing it would mean removing the framework's core value proposition.

Swift 6's strict concurrency model adds another dimension entirely. Data race conditions get caught at compile time, before the app ever ships, rather than surfacing as a crash on some user's device weeks later. React Native has no language-level equivalent to that guarantee.

Then there's platform depth. New Apple frameworks, including the on-device Foundation Models introduced at iOS 26, land in native Swift first, with React Native community wrappers following afterward. React Native community wrappers follow afterward, often with a real version lag, and that's before accounting for the 15% of packages still stuck on the old bridge. For anything graphics-heavy or compute-heavy, the Swift and Metal path has zero cross-language overhead, while React Native still routes application logic through the JS runtime even when Fabric is handling the final render natively.

None of this is a configuration problem waiting on a patch. The JS runtime is the product. Removing it removes React Native.

How to read these benchmarks as an engineer making a real architectural call

The 15.5% versus 1.6% frame-drop figure is a stress-test ceiling, not a Tuesday-afternoon average. Most apps never come close to that load profile, so treating it as representative of typical use would be a mistake.

The 50ms versus 70ms transaction gap matters enormously for specific kinds of surfaces: real-time drawing tools, audio scrubbing, gesture chains running at 60fps. For a content feed or a checkout form, that same gap is invisible to a human user. Context decides whether a number like this should change a decision or get filed away as irrelevant.

A few questions actually determine which gap applies to a given project. Is the product iOS-first, or does it need to ship on Android from shared logic? Does the roadmap depend on system integrations, ARKit, HealthKit, Core ML, on-device AI, that land in Swift before they land in any RN wrapper? What does the team's language footprint actually look like: per Statista's 2024 figures, 62.3% of developers use JavaScript against just 4.7% using Swift, and per Stack Overflow's 2025 survey, Swift is admired by 51.9% of developers who use it but only 5.9% plan to adopt it going forward. Hiring and onboarding costs sitting behind those numbers are real, not abstract. And finally: does the New Architecture's actual performance envelope, as benchmarked above, cover what this specific product needs it to do?

React Native's New Architecture is now a legitimate option for apps that would have been ruled out automatically five years ago. Legitimate is not the same word as equivalent, though, and treating them as synonyms is where architectural decisions go wrong. SwiftUI stays the right foundation whenever performance predictability, platform-native depth, or compile-time concurrency safety aren't negotiable. Those are engineering requirements, not stylistic preferences, and they don't bend to a team's framework loyalty.

Where the architectural choice intersects with on-device AI integration

Apple's Foundation Models framework, arriving with iOS 26, is directly accessible from native SwiftUI apps with no bridge layer sitting in between. That's a structural first-mover advantage, and it repeats every time Apple ships a new on-device AI capability: native Swift gets it immediately, everything else waits.

React Native's path to the same capability runs through a growing but still-intermediary set of libraries. The react-native-ai library, through @react-native-ai/apple, offers native integration with Apple's Foundation Models on iOS 26 devices, covering text generation, embeddings via NLContextualEmbedding, transcription via SpeechAnalyzer and SpeechTranscriber, and speech synthesis through AVSpeechSynthesizer. @react-native-ai/llama handles GGUF inference with streaming support and automatic model downloading and caching from Hugging Face, with support across iOS and Android. Software Mansion's react-native-executorch supports local model execution inside Expo apps, pulling from Hugging Face and supporting edge deployment scenarios. Together these give React Native a genuine unified provider model, letting engineers switch between cloud and on-device LLMs without rewriting application logic.

That ecosystem is real and it works. But it still adds a wrapper layer between the application and the Apple-native model runtime, and that wrapper carries a latency and capability lag relative to the native path. For agentic iOS systems, tool calling, structured outputs, real-time inference woven directly into gesture-driven UI, the native Swift path removes every intermediate layer standing between the model and the screen. This is arguably the frontier where the performance delta discussed above carries the most direct product consequence. Engineers building AI-native mobile products need to weigh not just today's capability parity but how quickly each path gets access to whatever Apple ships next.

What this means for iOS engineers deciding where to invest their expertise

React Native's New Architecture has earned a real seat at the table in serious iOS engineering discussions. The old objections rooted in bridge-era limitations no longer apply to any team that has fully migrated past RN 0.82, and pretending otherwise at this point is just outdated thinking.

The remaining performance delta is real, but for most product surfaces it's narrow enough to not be the deciding factor. It becomes decisive at the performance ceiling, under heavy load, or on integrations that reach deep into the platform.

SwiftUI paired with Swift 6 is the right foundation when the product is iOS-first with no real cross-platform need, when performance predictability and compile-time safety are actual requirements rather than nice-to-haves, or when the roadmap depends on tight Apple platform integration, including on-device AI at the system level.

React Native's New Architecture is the right call when shared iOS and Android logic is a genuine product constraint, not a premature optimization dressed up as one, when the team's language footprint already skews JavaScript and the hiring pool is a real cost to weigh, and when the app's interaction model stays comfortably within the performance envelope the benchmarks above confirm is now covered.

The engineers who can make this call correctly are the ones who understand both architectures at the level of mechanism, not just the API surface each one exposes. This is a systems judgment, not a matter of framework preference or personal taste. Understanding precisely where the New Architecture closes the gap, and where it structurally cannot, is what separates a senior architectural opinion from a default assumption carried over from five years ago.