AI is changing the economics of native apps.
In the age of agentic coding, why would we continue making compromises such as React Native or Electron?
Cross-platform frameworks are a cost compromise — and AI just collapsed the cost. Define the product once. Build it properly for every platform.
- React Native and Electron exist because building twice was expensive; users pay for that savings with common-denominator apps.
- AI agents can translate one spec into Swift and Kotlin, test both, and keep them aligned — the duplication objection is dissolving.
- Abstractions leak: platform differences don't disappear, they hide — until teams maintain the framework, the exceptions, and native patches.
- Anthropic shipping Claude as an Electron Mac app is the contradiction in one product: the tool that accelerates development, delivered via a shortcut.
- Cross-platform still has legitimate uses — but for serious consumer products, native should be the default again and the burden of proof should flip.
AI should be the cross-platform framework
In the age of agentic coding, why would we continue making compromises such as React Native or Electron?
These frameworks exist for an understandable reason: building the same product several times is expensive. Companies want to write an application once, share as much code as possible, and deploy it everywhere. React Native promises this for iOS and Android. Electron extends the idea to the desktop.
The trade-off has always been that users receive an application designed around the common denominator rather than the platform in their hands.
Now that AI can write and maintain code at extraordinary speed, that trade-off deserves to be reconsidered.
Development costs and risks have not disappeared, but the cost of producing code has fallen dramatically. A capable coding agent can translate a feature specification into Swift for iOS and Kotlin for Android. It can write tests for both implementations, track down differences between them, and help keep their behavior aligned.
The new model does not have to be "write once, run anywhere." It can be:
Define the product once. Build it properly for every platform.
For iOS, that means Swift, SwiftUI, UIKit, and Apple's SDKs. For Android, it means Kotlin, Jetpack Compose, and the Android SDK. Each application can use the navigation conventions, accessibility features, system controls, animations, performance characteristics, and hardware capabilities its users expect.
That is not wasteful duplication. It is respect for the platform.
The abstraction eventually leaks
React Native is capable of producing good applications. Some excellent products use it. But it does not eliminate the differences between iOS and Android; it moves those differences behind an abstraction.
Sooner or later, that abstraction leaks.
A feature behaves differently on one platform. A third-party package wraps only part of a native API. An operating-system update breaks the bridge. A performance problem requires dropping into Swift or Kotlin. A design that looked consistent in a mockup feels subtly wrong when placed beside genuinely native applications.
At that point, the team is no longer maintaining one codebase. It is maintaining a shared abstraction, two sets of platform-specific exceptions, a collection of dependencies, and whatever native code was required to fill the gaps.
The same problem appears on the desktop with Electron. Electron makes it convenient to package a web application for macOS, Windows, and Linux, but convenience for the development team is not necessarily quality for the user. The result can be a large installation, high memory consumption, unfamiliar controls, and an application that never quite belongs on any of the platforms it supports.
The Claude app is the perfect example
John Gruber makes this argument far more colorfully in "Claude's Criminally Bad Electron Mac App Is an Inside Job".
Claude is one of the most capable coding agents available, yet Anthropic's macOS application is built with Electron. It is difficult to imagine a better demonstration of the contradiction. The product that is supposed to make software development dramatically faster is itself delivered using a framework chosen primarily to avoid developing separate native applications.
As Gruber points out, developers are already using Claude Code to build polished native Mac applications. If individuals and small teams can do that with AI assistance, why should one of the world's leading AI companies settle for an application that carries an entire web runtime and still does not feel at home on the Mac?
Gruber's wonderfully sharp summary is that Electron ensures an app "feels just as wrong on all platforms." That is the hidden cost of uniformity: consistency is achieved by making every version foreign in the same way.
His more recent criticism of the new ChatGPT and Codex Mac experience reaches a related conclusion. Software can be enormously capable and still be an incoherent product. Confusing installation and migration behavior, which he documents in his earlier post about "ChatGPT Classic", only reinforces the point: implementation convenience is not the same thing as a good user experience.
Users do not care how much code was shared. They care whether the application is fast, predictable, accessible, and pleasant to use.
Let AI maintain the duplication
The traditional objection to native development is straightforward: two applications require two teams, two implementations, and twice the maintenance.
AI changes that calculation.
A company can maintain a shared product specification, API contract, design language, and test suite while generating platform-specific implementations. When a feature changes, an agent can update both codebases. When Apple or Google introduces a new platform capability, each application can adopt it directly instead of waiting for a cross-platform framework and its dependencies to catch up.
There will still be difficult work. Architecture, product judgment, design, testing, security, and the final layer of polish do not disappear because an agent can produce code. Native applications may even expose more platform-specific edge cases.
But that last 10 percent has always been difficult. Choosing React Native does not remove it. In some cases, it makes the work harder because developers must fight both the underlying platform and the abstraction placed on top of it.
If AI makes the first 90 percent much cheaper, it becomes increasingly difficult to justify compromising the entire application to save effort there.
Native should become the default again
This does not mean React Native, Flutter, or Electron suddenly have no legitimate uses. They remain practical for prototypes, internal tools, small teams with strong web expertise, and products where speed to market matters much more than platform integration.
But they should no longer be the automatic choice.
For a serious consumer product expected to live on someone's phone for years, the burden of proof should shift. Why should an iPhone application not be built as an iPhone application? Why should an Android app not take full advantage of Android? Why should a Mac app arrive with a browser engine attached when the platform already provides everything required to build a great application?
The original promise was: write once and deploy anywhere.
The better promise for the age of AI is: design once, then build the best possible application everywhere.
Frequently asked questions
Why do cross-platform frameworks like React Native and Electron exist?
Because building the same product several times is expensive. Companies want to write an application once, share as much code as possible, and deploy it everywhere. React Native promises this for iOS and Android; Electron extends the idea to the desktop. The trade-off has always been that users receive an application designed around the common denominator rather than the platform in their hands.
How does AI change the case for native app development?
AI collapses the cost of producing code — the main justification for cross-platform compromise. A capable coding agent can translate one feature specification into Swift for iOS and Kotlin for Android, write tests for both implementations, track down differences between them, and keep their behavior aligned. The model shifts from "write once, run anywhere" to "define the product once, build it properly for every platform."
Are React Native, Flutter, and Electron obsolete?
No. They remain practical for prototypes, internal tools, small teams with strong web expertise, and products where speed to market matters much more than platform integration. The argument is that they should no longer be the automatic choice — for a serious consumer product expected to live on someone's phone for years, the burden of proof should shift toward native.
Doesn't maintaining two native codebases double the work?
Traditionally yes — two apps meant two teams and twice the maintenance. With AI agents, a company can maintain one shared product specification, API contract, design language, and test suite while generating platform-specific implementations. When a feature changes, an agent updates both codebases. The difficult last 10 percent — architecture, design, polish — never disappeared under cross-platform frameworks anyway; abstraction often made it harder.
Staff mobile engineer in Vancouver, BC. Fifteen years shipping native and cross-platform apps — currently owning the consumer mobile app at Trustworthy on Expo and React Native, with native modules in Swift and Kotlin.