Cross-platform is a promise you make to your budget
Write once, run anywhere, debug everywhere. The honest accounting of what each approach actually costs.
The cross-platform question — one codebase or several — gets argued as a technical matter and is mostly an organizational one. Here is the honest accounting.
the actual trade#
Native gives you: full platform capability, best performance, platform-idiomatic interface, immediate access to new OS features, and the best debugging tools.
It costs you: two or three codebases, two or three teams, features implemented multiple times, and behavior that diverges over years in ways nobody tracks.
Cross-platform gives you: one codebase, one team, features implemented once, consistent behavior.
It costs you: a framework layer between you and the platform, a lag before new OS features are available, worse debugging when the problem is in the bridge, and an interface that is either non-idiomatic on every platform or requires platform-specific work anyway.
the thing the arguments miss#
The largest cost of cross-platform is not performance. It is the escape hatch.
Everything is fine until you need something the framework does not support. Then you are writing platform-specific native code, plus a bridge, plus a fallback, plus tests for all three — and you have the complexity of native development plus the framework.
This happens. It always happens. The question is how often, and that depends entirely on what your app does.
Low escape-hatch pressure: content, commerce, forms, dashboards, CRUD, most business applications. These use the standard widget set and standard capabilities. Cross-platform works well.
High escape-hatch pressure: camera and media processing, background execution, Bluetooth and hardware peripherals, complex custom rendering, deep platform integration (widgets, shortcuts, app extensions), anything real-time.
For high-pressure apps, cross-platform frequently costs more than native, because you pay for the framework and then write the native code anyway.
Be honest about which one you are before choosing. Most teams that regret their choice were high-pressure and assessed themselves as low.
the options, honestly#
React Native. Mature, large ecosystem, native widgets. The new architecture removed the old asynchronous bridge, which was the main performance complaint. Best choice if your team is already React.
Flutter. Renders its own widgets, which means true visual consistency and a non-native feel that some users notice and most do not. Excellent performance for custom interfaces. Dart is a real adoption cost for a team that does not know it.
Kotlin Multiplatform. Share business logic, write native UI. This is the approach I find most defensible: the logic layer — networking, models, validation, persistence — is where duplication is most wasteful and least visible to users, and the UI layer is where platform idiom matters most.
Requires two UI implementations, which is the point rather than a limitation.
Web technologies in a wrapper. Fastest to build if you have web engineers, and the platform feel is the weakest. Fine for content-heavy applications, poor for anything interaction-heavy.
Native. Still correct for a large category, and the category is smaller than native advocates believe.
the organizational question that actually decides it#
Do you have or can you hire two platform teams?
If yes, native is viable and gives you the best result.
If no — and for most companies below a certain size the answer is no — the choice is between cross-platform and shipping on one platform. Framed that way, the decision is usually easy.
What is your feature velocity?
If you ship a large feature monthly, implementing it twice is a permanent 2× cost on your most expensive activity. If you ship quarterly, the duplication matters less.
How much does platform idiom matter to your users?
For a consumer app competing on polish: a lot. For an internal tool: nothing. For a B2B product where the buyer is not the user: less than you think.
the hybrid that most people should consider#
Share the logic, write the UI natively.
The business logic — API clients, data models, validation, offline storage, sync, analytics — is genuinely identical across platforms and duplicating it produces bugs that exist on one platform and not the other, which are the worst bugs to diagnose.
The UI is where platform conventions matter, where users notice, and where the framework abstraction costs the most.
This is more work than full cross-platform and less than full native, and it puts the sharing where the value is.
the thing I would tell someone deciding#
Prototype the hardest thing first.
Not the login screen. The thing you are worried about — the camera flow, the background sync, the complex list, the offline behavior. Build that on your candidate stack, in a week.
You will learn more from that week than from any amount of comparison, and you will learn it while changing your mind is still cheap.
The teams that regret their choice almost always chose based on a comparison article, built the easy part first, and discovered the hard part in month five.
— Dom, June 30, 2026