Cross-Platform vs Native: The Honest Assessment Nobody Gives You
The cross-platform vs native debate has a quality problem: the people most qualified to give objective assessments have financial or professional stakes in one answer. Agency developers who charge by the hour prefer native because it doubles the billable work. Cross-platform framework vendors publish benchmark comparisons designed to minimize the gaps between their output and native. Native platform advocates at Apple and Google have obvious incentives to characterize cross-platform output as inferior.
The honest answer is more specific than either camp’s marketing allows: cross-platform is the right choice for a well-defined set of requirements, and native is the right choice for a different well-defined set. The error is treating the choice as absolute rather than contextual.
What Cross-Platform Actually Costs
The promise of cross-platform frameworks is code reuse: write once, ship to both platforms. The reality is code reuse for most of the application with platform-specific code for the parts that cannot be abstracted. The ratio of shared to platform-specific code depends on how deeply the application integrates with platform capabilities.
An application that is primarily UI over a backend API — a news reader, a to-do list, an e-commerce catalog — can achieve 80 to 90 percent code sharing across platforms with React Native or Flutter. The 10 to 20 percent that requires platform-specific handling covers things like push notification configuration, background processing, biometric authentication, and deep links. The code sharing is real and the developer time savings are real.
An application that integrates deeply with platform capabilities — a camera app that processes video in real time, a health app that reads continuous sensor data, a navigation app that uses background location — will find the shared code percentage dropping and the platform-specific workarounds multiplying. The framework does not prevent building these features. It makes them harder than they would be in native code, and the resulting implementation is more complex to maintain than the equivalent native code.
The Performance Gap
The performance gap between cross-platform and native has narrowed significantly since the early days of both React Native and Flutter. It has not closed. The gap manifests in specific, measurable ways: startup time on lower-end devices, frame rate during complex animations, battery consumption under sustained use.
For the median use case — a content app on a mid-range device — the gap is not perceptible to users. For the tail cases — heavy graphical content on old devices, animation-heavy experiences, real-time data processing — it is. The question is whether the tail cases are populated by your users.
Team and Maintenance Considerations
The choice that most teams get wrong is treating cross-platform as a permanent reduction in required expertise. Cross-platform frameworks reduce the amount of platform-specific code, but they do not eliminate the need for developers who understand iOS and Android behavior. A React Native team that has nobody who understands the iOS rendering stack or the Android process lifecycle will struggle when their cross-platform abstraction fails to handle a platform-specific edge case — which it will.
The teams that use React Native and Flutter most successfully maintain some native expertise. They treat the cross-platform framework as leverage for the majority of development work and retain the ability to drop into platform code when the abstraction breaks. The teams that treat cross-platform as a way to avoid native expertise entirely accumulate technical debt in the form of unresolved platform-specific bugs and missed platform capability opportunities.
The Honest Recommendation
New consumer apps with teams that have frontend web development backgrounds and need to ship quickly to both platforms: start with React Native or Flutter. The speed to market advantage is real. The ability to hire from a larger talent pool is real. Invest in understanding the platform-specific layer as the product matures.
New apps with significant platform integration requirements — hardware access, real-time processing, deep OS integration — or teams with existing native expertise: build native. The cross-platform framework’s abstractions will add complexity in precisely the areas where the application’s value requires the most direct platform access.
Large organizations with native mobile teams and significant existing codebases: evaluate Kotlin Multiplatform for sharing business logic while keeping UI native. The approach avoids the rendering and platform integration trade-offs of full cross-platform frameworks while capturing the code sharing benefit where it is least costly.
The choice is not about which framework is better. It is about which trade-offs your specific project can absorb.