Guide · structural argument, zero borrowed benchmarks
React Native or native Swift & Kotlin: which should your app be built in?
For a decade this was a forced trade: one codebase and one team with React Native, or two better apps at twice the cost with native. The 2026 twist is that the trade is no longer forced — AI agents write the native code, and shared-core architecture gives one project two genuinely native apps. Here is the decision as it actually stands now.
First, what the two options actually are — because the marketing fog around "native" does real damage here.
React Native writes your app once, in JavaScript or TypeScript (the framework is Meta's), and drives each platform's native components from that shared code. It is not a website in a wrapper — the buttons and lists on screen are real platform components — but your code reaches them through a JavaScript layer, and that layer is where both the economy and the trade-offs live.
Native means each platform's first-party stack: Swift with SwiftUI on iOS, Kotlin with Jetpack Compose on Android. Nothing between you and the platform: when Apple or Google announces a new capability, it lands in these stacks on day one, because these stacks are what the announcement is written in. The historical price was writing — and staffing — everything twice.
Neither is a mistake. The question is which trade-offs your product can afford, and whether you are still forced to make the classic trade at all.
The honest case for React Native
Three arguments carried React Native for a decade, and all three still stand for the right team.
The team you have. If your engineers are JavaScript engineers, RN turns them into mobile engineers this quarter — no other consideration on this page outweighs that for a company shipping now with the people it employs.
One surface to change. A pricing update, a new flow, a bug fix: once, not twice. For products that iterate weekly across both stores, that operational economy compounds.
A mature, enormous ecosystem. Expo's tooling, a decade of libraries, and answers to every question you will ever ask, already on Stack Overflow. In the AI era this matters twice over: RN's entry cost keeps falling, and vibe-coding tools like Rork Pro ($20/month) make it a prompt-based route too.
Where the bill arrives — structurally, not anecdotally: platform-deep features (the newest OS capabilities, platform-exact behaviours, heavy platform integrations) reach you through the JS layer and community wrappers, on a delay you don't control; the app's feel is very good but converges on "very good cross-platform" rather than "indistinguishable from the platform"; and performance tuning eventually means understanding the native layer anyway — the abstraction is a loan, not a gift, and platform-deep products repay it with interest.
The honest case for native — and its historical problem
The case for Swift/SwiftUI and Kotlin/Compose is short because it is structural: first-party stacks are where the platform actually lives. Day-one access to every OS capability, platform-exact look and behaviour by default rather than by effort, the platform vendors' own tooling and AI agents pointed at exactly this code (Xcode 26.3 ships Claude and Codex agents as a stable feature), and a codebase any iOS or Android developer on earth can maintain — the deepest hiring pools in mobile, on the code they already know.
The historical problem was never quality; it was economics. Two languages, two codebases, two teams, every feature built twice and drifting apart between releases. That is the entire reason React Native exists, and for a decade it was a good enough reason. The interesting question of 2026 is whether it still holds.
What changed: the trade is no longer forced
Two shifts, both verifiable, dissolve the old dilemma's premises — this is our position, argued, and you can check each premise.
AI agents removed the double-writing cost. The expensive part of native was human hours in two languages. An agent writes Swift and Kotlin at the same conversational pace a human directs in — so "we'd have to build everything twice" became "the agent builds it twice while you review it once." The remaining question was consistency: what keeps two codebases from drifting apart?
Shared-core architecture removed the drift. Duet — ours; the mechanism is public — structures one project as a shared business-logic core with two native UI shells: real SwiftUI on iOS, real Kotlin/Compose on Android. The shared logic is enforced byte-identical on both platforms by replayed fixtures — the build fails on divergence — so you get React Native's "one product to reason about" with native's "two real platform apps." One team, one project, two first-party codebases you own.
What this means for the decision: RN's structural advantages were answers to a constraint that has weakened. The team-you-have argument still wins where it applies — a JS team is a JS team. But "we can't afford real native on both platforms" is no longer true by default: Modaal builds exactly this shape, free to start (one platform, unlimited prompts), €9/month billed annually for both platforms. The platform-first sequencing logic is in iOS or Android first.
The decision, as it stands in 2026
Choose React Native when: your JavaScript team is shipping now and retraining is off the table; your product is form-and-list shaped, iterates weekly, and platform depth is genuinely not on the roadmap; or your whole world already runs on Expo and the operational economy is proven in your own house.
Choose native (Swift + Kotlin) when: the product leans on platform capabilities — or will; the feel of the app is part of the product; you want the platform vendors' own AI tooling compounding in your favour; or you are starting fresh in 2026 with no legacy team constraint — in which case the old reason to accept the JS layer simply is not present.
The reframe worth taking away: this used to be a question about your budget. It is now a question about your team and your product — and if neither forces your hand, native stopped being the expensive option. For the iOS-only version of this comparison, see Swift vs React Native; for what actually produces native Android for non-developers, that field guide.
The trade-offs, side by side
| React Native | Native (SwiftUI + Kotlin/Compose) | |
|---|---|---|
| Code | One codebase, JS/TS (Meta-backed) | Two first-party codebases — or one project with a shared core (Duet) |
| UI | Real native components, driven through a JS layer | The platform’s own UI toolkit, platform-exact by default |
| New OS features | Via bridge/wrappers, on a delay you don’t control | Day one — the announcement is written in this stack |
| Team fit | JavaScript engineers, productive immediately | iOS/Android devs — or an AI agent writing both while you review |
| AI-era entry | Rork Pro $20/mo (credits) and the Expo ecosystem | Modaal free (unlimited prompts) · Xcode 26.3 agents on your AI plan |
| The loan you take | The JS layer — repaid with interest by platform-deep products | Historically double cost — dissolved by agents + shared core |
Vendor prices read 27 Aug–1 Sep 2026. No performance benchmarks appear here because we haven’t run any — the trade-offs above are structural and hold regardless of the benchmark of the week.
Frequently asked questions
Neither is universally better — the decision follows your team and product. React Native wins when a JavaScript team must ship now and the product is not platform-deep. Native (Swift/SwiftUI + Kotlin/Compose) wins on platform capabilities, day-one OS features, and feel. The 2026 change: AI agents plus shared-core architecture removed native’s traditional double cost, so cost alone no longer decides it.
Yes, for its remaining structural advantages: an existing JavaScript team, one surface to iterate weekly, and a huge mature ecosystem. What changed is the default for new projects without a JS-team constraint — the "we cannot afford two native apps" premise is no longer true by default, which was React Native’s founding argument.
That is what shared-core architecture does: Modaal’s Duet structures one project as shared business logic with two native shells — real SwiftUI on iOS, real Kotlin with Jetpack Compose on Android — with the shared logic enforced identical on both platforms (the build fails on divergence). One product to reason about, two first-party codebases you own; the mechanism is documented publicly.
The fair version: RN renders real platform components, and well-built RN apps feel very good. The structural gap is at the platform-exact edges — the newest OS behaviours, deep platform integrations, and fine-grained feel — which reach RN through a JavaScript layer and community wrappers rather than by default. Whether that gap matters is a product question: invisible in a form-and-list app, visible in a platform-deep one.
JavaScript is the larger general pool; iOS and Android are the deeper specialised ones — and every mobile-platform developer can maintain first-party Swift or Kotlin, while RN requires its own specific experience. In the AI era the sharper question is which codebase an agent maintains best under your review: first-party stacks are what the platform vendors’ own tooling (like Xcode’s built-in agents) is pointed at.
Keep reading
- React Native alternatives, sorted by why you are leaving
Six options matched to the reason, not to GitHub stars.
- Cross-platform app builders in 2026: what each one ships
Ten builders sorted by output — web shell, React Native, Flutter, or native.
- Swift vs React Native
The iOS-only version of this decision.
- The fastest way to build an iOS app
Speed physics across every route.
- iOS or Android first?
The platform-sequencing question.
- Best AI tools for native Android apps
Who actually outputs Kotlin — the short list.