AI Makes Native Apps Affordable Again
For years, the economics of software development pushed teams toward a familiar compromise: build one application, then stretch it across every platform.
That compromise gave us React Native on mobile and Electron on desktop. Both solved a real business problem. Writing and maintaining separate applications for iPhone, Android, Mac, and Windows required more engineers, more time, and more money than many companies could justify.
But the premise behind that decision is beginning to change.
Coding agents can now produce substantial amounts of Swift, Kotlin, C#, and other platform-specific code from the same product requirements. They can carry a feature across multiple repositories, generate tests, compare implementations, and help diagnose platform-specific failures.
When code becomes less expensive to produce, sharing every possible line of it stops being the only sensible strategy.
The goal can shift from one codebase running everywhere to one product built well everywhere.
Cross-platform development was an economic decision
Cross-platform frameworks are often discussed as if they are purely technical choices. In practice, the strongest argument for them has always been cost.
A company wants to launch on iOS and Android without staffing two complete engineering teams. A web team wants to deliver a desktop application without learning AppKit, WinUI, or the details of each operating system. Sharing code appears to turn several expensive projects into one manageable project.
Users pay for that efficiency in small ways.
The application may use controls that look almost native but behave a little differently. Navigation can follow the framework’s conventions instead of the operating system’s. New platform features arrive only after a library supports them. Performance problems sometimes require work in both the abstraction layer and the native layer beneath it.
None of this means that cross-platform applications are automatically poor. Talented teams have shipped excellent software with React Native, Flutter, and Electron. The point is that the approach exchanges some platform fidelity for organizational efficiency.
AI is lowering the price of that efficiency.
Shared code is not the same as shared behavior
The promise of a common codebase sounds wonderfully simple. In production, platforms refuse to remain identical.
iOS and Android have different navigation models, permission systems, background-execution rules, accessibility APIs, interface conventions, and release cycles. macOS and Windows users expect different menus, keyboard behavior, window management, and system integration.
A framework can hide these differences for a while. It cannot make them disappear.
Eventually, teams accumulate exceptions:
- a native module for an API the framework does not expose;
- a conditional branch for behavior that differs on Android;
- a replacement package because an operating-system update broke the old one;
- a custom performance fix that bypasses the shared layer;
- a platform-specific design adjustment because the common component feels wrong.
The supposedly single application becomes a shared core surrounded by platform branches, bridge code, third-party dependencies, and native escape hatches. Teams still do platform-specific work; they simply do it through an additional layer.
That layer has a cost of its own. Every abstraction must be learned, updated, debugged, and reconciled with the systems underneath it.
Desktop wrappers make the trade-off especially visible
Electron takes the web technologies a team already knows and packages them as desktop software. That makes distribution convenient, but it also means shipping a browser runtime with the application.
The consequences are easy to notice: larger downloads, heavier memory use, controls that do not quite match the operating system, and an experience that can feel more like a website in a window than a Mac or Windows application.
The contrast is particularly striking in AI products. The Claude desktop app, for example, has been criticized for using Electron even though Claude itself can help developers create polished native Mac software. The technology presented as a dramatic accelerator for programming is delivered through an architecture historically chosen to avoid writing more platform-specific code.
That contradiction points to the larger opportunity. If an individual developer can use an agent to build a native application, a well-funded software company should at least reconsider whether a web wrapper is still the right default.
Users never see a code-sharing percentage. They experience startup time, memory consumption, keyboard shortcuts, accessibility, scrolling, window behavior, and whether an application seems to belong on their device.
Let the agent handle repetition
Traditional native development often meant duplicating work manually. A feature implemented in Swift had to be implemented again in Kotlin. Bugs could be fixed on one platform and accidentally left behind on the other. Keeping behavior aligned required constant communication between specialized teams.
AI makes a different workflow possible.
A company can define the product in shared artifacts: feature specifications, API schemas, design rules, analytics events, acceptance tests, and expected behavior. Coding agents can then use those artifacts to implement the product separately for each platform.
In that model, the specification is shared even when the interface code is not.
When a requirement changes, an agent can update both implementations and their tests. When Apple releases a new framework, the iOS application can adopt it directly. When Android introduces a new device capability, the Android application does not need to wait for a cross-platform package to expose it.
SwiftUI can behave like SwiftUI. Jetpack Compose can behave like Jetpack Compose. Each version can use the controls, animations, accessibility features, hardware integrations, and performance tools provided by its platform.
Duplicated code is less frightening when machines perform much of the duplication.
The difficult work is still difficult
AI does not remove the need for engineering judgment.
Teams still need to make sound architectural choices, protect user data, design coherent experiences, test real devices, handle unusual states, and decide which features are worth building. Agents can also introduce bugs or reproduce a flawed requirement across every implementation with impressive speed.
Native development exposes platform-specific edge cases that a shared framework may smooth over. Multiple applications still need ownership, review, release management, and careful quality assurance.
Yet cross-platform tools never eliminated the hardest part of building a great product. They mostly reduced the amount of routine implementation needed to reach it. The final stretch—polish, performance, reliability, and platform fit—remained difficult and sometimes became harder because engineers had to work around the abstraction too.
If agents dramatically reduce the cost of routine implementation, compromising the full user experience to save that work becomes a weaker bargain.
Native deserves to be the starting point
React Native, Flutter, and Electron will continue to be useful. A prototype that must ship next week may benefit from one shared codebase. An internal tool may not need deep platform integration. A small company with extensive web expertise may reasonably value delivery speed above native detail.
The change is not that cross-platform development becomes invalid. It is that it should no longer win automatically.
For a consumer application expected to remain on someone’s phone or computer for years, teams should begin with a different question: what prevents us from building this properly for each platform?
An iPhone app can use Swift, SwiftUI, and Apple’s frameworks directly. An Android app can embrace Kotlin, Jetpack Compose, and Android’s own design patterns. A desktop app can use the windowing, menus, accessibility, and performance characteristics its users already understand.
The old ambition was to write the product once and run it everywhere.
The AI-era ambition is better: define the product once, then let every platform receive the version it deserves.