Nobody Wants to Admit AI Just Made React Native Obsolete
In this article
Bottom line: React Native's core pitch — write once, ship to iOS and Android — no longer requires React Native.
After rebuilding a fintech client's app in native Swift and Kotlin using Claude Code and Cursor in August 2026, I shipped both platforms in nine working days instead of the six weeks the original React Native build took.
The bridge layer that made cross-platform frameworks worth the tradeoffs is now a bottleneck AI coding tools route around entirely, generating parallel native implementations from one shared spec.
React Native isn't disappearing overnight, and Expo still has a real audience, but the argument for defaulting to it just quietly collapsed.
If your team picked React Native purely for velocity, that math changed sometime in the last year, and almost nobody's recalculated it.
React Native isn't dying because Meta stopped caring about it.
It's dying because Claude Code can generate me a working SwiftUI screen and a working Jetpack Compose screen from the same product spec faster than I can `npm install` a cross-platform bridge, configure the native modules, and pray the next Expo SDK bump doesn't break my camera permissions again.
I know how that sounds. I've spent a decade telling junior engineers that cross-platform frameworks are the responsible choice for small teams.
I was wrong about the timeline, not the logic — the logic mattered right up until AI made "write once" a solved problem in a completely different way than React Native solved it.
The Setup: A Fintech App That Wouldn't Stop Lagging
In August 2026, a fintech client came to me with a React Native app that had a real problem: the biometric auth flow was janky on older Android devices, and every fix touched three layers — the JS logic, the bridge, and a native module somebody hired a contractor to write two years ago and never documented.
Classic React Native tax.
The original build took a four-person team six weeks.
My mandate this time was narrower: rebuild the core flows — auth, balance view, transfer confirmation — as fully native apps, one in Swift/SwiftUI, one in Kotlin/Jetpack Compose, and see if it was actually feasible without doubling the team.
I didn't hire anyone.
I ran Claude Code against a single shared spec document — screens, state transitions, API contracts — and had it generate both native implementations in parallel sessions, one targeting iOS, one targeting Android.
Cursor handled the inline edits and refactors once the scaffolding existed.
The Core Insight: The Abstraction Tax Nobody Talks About
React Native's entire value proposition rests on one assumption: writing native UI code twice is expensive enough that a shared JavaScript layer, plus a bridge to native APIs, is worth the overhead it introduces.
That assumption held for a decade. It doesn't hold anymore, and here's specifically why.
The bridge was never actually free. Every React Native team I've worked with eventually hits the same wall — a native module that doesn't exist yet, a performance-critical screen that needs to drop to native anyway, a platform API that the bridge hasn't caught up to.
You end up maintaining JavaScript, a bridge layer, and native code. That's three surfaces instead of two.
What Actually Happened On My Last Project
I fed Claude Code the same spec twice — once framed for SwiftUI, once for Jetpack Compose — and let it work through the screens independently.
The auth flow, which had been the buggiest part of the original app, took about four hours per platform to get to a working state, including the biometric integration that had caused the original problems.
The full rebuild — three core flows, two platforms — took nine working days total, done by me alone with AI doing the bulk of the boilerplate and platform-specific plumbing.
The original React Native version took six weeks with four engineers. That's not a marginal efficiency gain; that's the entire cost structure that justified cross-platform frameworks getting inverted.
The code quality difference mattered too.
Native SwiftUI and Compose code generated against a clear spec doesn't have to route camera access, biometric prompts, or push notification handling through a translation layer that somebody else wrote in 2019 and stopped maintaining.
The AI-generated native code was more debuggable than the bridge code it replaced, because there was one less layer of indirection between the bug and the fix.
The Real Threat Isn't the Framework, It's the Justification
Here's the part that's uncomfortable to say out loud in a React Native Slack channel. The framework was never really the product.
The product was velocity — fewer engineers, one codebase, faster iteration.
AI coding tools attack that exact same value proposition, but from the native side, which means React Native now has to justify its bridge overhead against a baseline that no longer needs it.
I ran an informal poll across a founder Slack I'm part of — about 40 startup CTOs — in early September.
Eleven said they'd started at least one new mobile project in native Swift/Kotlin with heavy AI assistance instead of defaulting to React Native or Flutter, specifically because the "two codebases" argument stopped scaring them.
That's a small sample, but it's a real shift in a group that would've unanimously reached for a cross-platform framework two years ago.
The Reality Check: Where This Breaks Down
I'm not going to pretend this generalizes cleanly, because it doesn't.
If your team already has a huge React Native codebase, this isn't an argument to rewrite it — migration cost dwarfs any velocity gain, full stop.
AI-generated native code still requires two sets of platform expertise to review it properly. Claude Code and Cursor are good at generating idiomatic SwiftUI and Compose, but somebody on your team needs to know enough about both platforms to catch the subtle stuff — memory management quirks, App Store review gotchas, platform-specific accessibility requirements.
If nobody on your team has ever shipped a native iOS app, AI closes the gap but doesn't erase it.
The other place this breaks: teams that share substantial business logic between a React web app and a React Native mobile app.
If your value is in reusing hooks, state management, and validation logic across web and mobile — not just UI — React Native and Expo still win, because AI doesn't replace the pain of maintaining fully separate business logic implementations across three codebases instead of one.
That's a real, durable use case, and it's a big chunk of why Expo isn't going anywhere in 2027.
I'd also flag that my nine-day number was a rebuild of known flows against an existing spec, not a greenfield product with undefined requirements.
Ambiguity is still where AI-assisted development, native or cross-platform, loses time — the tool is fast once you know exactly what you're building, and slower than a whiteboard session when you don't.
The Practical Takeaway: Audit Your Actual Reason
If you're picking a mobile stack for a new project between now and mid-2027, don't ask "React Native or native?" as a framework question.
Ask why you'd choose React Native specifically, and check if that reason survived contact with AI-assisted native development.
If the honest answer is "one codebase means fewer engineers and faster shipping," run a real test before committing: take one non-trivial screen, generate it natively for both platforms with Claude Code or a comparable tool, and time it against what a React Native implementation would take with the same spec.
I've been surprised twice now by how often native wins that specific race in 2026, and it's worth being surprised on a throwaway screen rather than six weeks into a production build.
If the honest answer is "we share 60% of our logic with our existing React web app," keep React Native — that reason didn't change, and it's not going to.
The mistake isn't choosing cross-platform frameworks.
It's choosing them on inertia instead of checking whether the assumption underneath them still holds, the same discipline that ought to apply to any productivity claim AI coding tools make about themselves.
Have you actually run this comparison on a real screen, or are you still assuming React Native is the safe default because it was in 2023? What did you find?
