Swift or React Native?

Most Swift-versus-React-Native articles were written about a React Native that is gone.

For years, the standard criticism was "the bridge" — a slow messaging layer between JavaScript and the native platform that made React Native apps feel a step behind. That criticism is out of date. React Native replaced the bridge entirely: the New Architecture became the default in late 2024, and since October 2025 it is the only architecture — the setting to switch back does nothing. The old code stopped shipping in iOS builds in early 2026.

This matters for your decision in two ways. If you ruled out React Native years ago because of sluggishness, the picture has genuinely improved and deserves a fresh look. And if you are reading a comparison right now that talks about "the bridge" as a present-day problem — including some that rank very well for this exact search — you are reading about 2023.

Current versions, so you can date any advice you find: React Native 0.87, Swift 6.3, Expo SDK 57. Anything comparing older versions is comparing history.

Here is something worth knowing before you weigh anyone's numbers, including ours: nobody has an official benchmark comparing React Native to native. Not Meta. Not Apple. We went looking, because we wanted to cite one.

What exists is Meta measuring React Native against its own previous version — real improvements, but self-comparison. Every "React Native is 95% as fast as native" figure you have seen comes from a blog post or a vendor, in one direction or the other. We are not going to add another invented percentage.

What we can tell you is the one structural fact React Native's own documentation is candid about: work driven by the JavaScript side can drop frames when that side is busy, and work on the native side cannot. Their docs even note that native-driven screen transitions are smoother than JavaScript-driven ones for exactly this reason.

What this means for your decision, in plain terms: for most apps — forms, feeds, lists, checkout flows — you will never feel the difference, and performance should not be the thing that decides this. Where you might feel it is at the edges: heavy animation while data loads, very long lists, anything where the interface must respond during hard work. If your app lives at those edges, that is a real point for Swift. If it does not, stop weighing performance and decide on the things below, which matter more.

1. Does your app need to work when nobody has it open? Home-screen widgets. Live Activities on the Lock Screen. A watch face complication. Background sync. Reminders that fire. These live on the operating system's own surfaces, and they are built natively — React Native does not reach them. Plenty of React Native apps ship native widgets on the side, but then "one codebase" comes with an asterisk. If OS surfaces are central to your product, that is the strongest single argument for Swift.

2. Do you actually need Android? Not "would be nice someday" — need, now, because your users are there. If yes, React Native's core promise applies: one team, one codebase, both stores. If no, you would be accepting a translation layer between you and your only platform in exchange for nothing. Apple-only products should default to Swift.

3. Who is going to build this? The unglamorous question that decides more projects than any benchmark. A team that writes React ships React Native in weeks; the same team learning Swift ships in months. If you are hiring, the pool is different too — the last year both stacks were measured together, React Native developers outnumbered Swift developers roughly two to one. If speed-to-launch with the people you have is the constraint, that can legitimately outweigh everything else on this page.

4. How long will this app live? An app you will replace in eighteen months should take the fastest path — probably React Native or no native app at all. An app you will still be maintaining in five years should weigh what an abstraction layer costs over that time: waiting on the ecosystem when Apple ships something new at WWDC, debugging through an extra layer, and — a small planning fact worth knowing — even Expo, the way most teams use React Native, typically tracks one version behind React Native itself.

5. Is the feel of the app part of the product? The scroll that decelerates just right. The back-swipe that follows your thumb and reverses when you hesitate. The keyboard that gets out of the way properly. Users cannot name any of this; they experience it as "expensive" or "cheap." React Native has closed most of this gap and closes more each year — but native is where the gap is zero. For a utility, this does not matter. For something people open twenty times a day and judge with their thumbs, it is most of the quality they perceive.

Because a page on a native-tooling site owes you the other side, stated fairly.

React Native at scale is not a gamble — Instagram, Microsoft Office, Outlook, Amazon Shopping, Kindle and all of Shopify's mobile apps use it. (A fair footnote: "uses React Native" and "is entirely React Native" are different claims, and public showcases only support the first. But the direction is clear — this is proven infrastructure.)

The ecosystem is enormous, most problems have a maintained package, and shipping a JavaScript-level fix without waiting on app review is genuinely valuable when something is broken in production.

One thing worth knowing if you go this way: Expo — the framework most React Native teams actually build with — is refreshingly direct that its friction-free preview app is for learning, not shipping. Their own docs say it "is limited and not useful for building production-grade projects" and recommend development builds for any real project. Plan for that from day one and it costs you nothing; discover it in month two and it costs you a bad week.

And one stale worry to retire on the Swift side while we are being fair in both directions: Swift 6's strict concurrency checking — which had a reputation for painful migrations — is opt-in. You adopt it on your schedule, and the last two Swift releases were largely about making it easier. Nobody is forced into it.

The question "Swift or React Native" quietly assumes an app is one codebase. There is a middle position that deserves to be in every version of this debate and rarely is: write the rules once, write each interface natively.

The idea: what actually drifts apart when you build an app twice is not the buttons — it is the behaviour. What counts as a valid password. What happens when the network fails mid-payment. What the retry policy is. Share that layer across platforms, and let iOS render it in SwiftUI and Android in Jetpack Compose, each feeling fully like itself.

This is a mature category now, not an experiment — even the best-known tooling in this space recommends keeping the UI native "when UX precision is key and platform fidelity matters," which is a framework vendor telling you where sharing should stop.

The catch, and it is real: shared logic only prevents drift where the sharing reaches, and discipline erodes. Someone fixes a bug on one platform, forgets the other, and six months later "the same app" is two apps that mostly agree. If you take this path — with any tooling — insist on one thing: a mechanism that fails the build when the platforms disagree, rather than a code-review habit that decays.

We build in that third category, so read this paragraph knowing we are not neutral.

Modaal builds native apps from plain-language descriptions using the AI coding agent you already subscribe to — real Swift and SwiftUI for iOS, real Kotlin and Jetpack Compose for Android, as ordinary projects on your own disk. Duet is our version of the shared-logic path: each feature's logic is written once, each platform renders it natively, and parity is enforced the way we just argued it must be — behaviour is recorded as fixtures, both platforms replay them, and the build fails if the two apps stop agreeing.

Who this is actually for: someone starting a new app who wants it on both platforms without running two teams — or starting on iOS and wanting Android to be a decision already banked, not a rewrite. If you are Apple-only forever, plain Swift is the honest recommendation and half this page already made it. And the practical constraints: a Mac, Xcode 26 or newer, about 50 GB of disk, and a willingness to see code even though you will not be writing it.