Native vs Cross-Platform App Development — How to Actually Choose
Cross-platform development builds one codebase that ships to both the App Store and Google Play, at roughly half the cost of two native builds. Native wins only when the app depends on deep platform capabilities — heavy Bluetooth, background processing, or console-grade graphics. For everything else, paying double buys you nothing users can see.
The question behind the question
"Native or cross-platform?" is really "should I build my app once or twice?" — because that is the entire operational difference. Native means a Swift codebase for iOS and a Kotlin codebase for Android: two builds, two maintenance streams, every feature twice, forever. Cross-platform — React Native in my work, Flutter being the credible alternative — means one codebase producing genuine apps for both stores.
I ship cross-platform apps for a living (all four of my production apps are React Native), so audit my bias — and note that this article contains a section arguing against my own service.
| Cross-platform | Dual native | |
|---|---|---|
| Codebases | One | Two |
| Build + maintenance cost | ≈ half | Full, twice |
| Feature parity between stores | Automatic | Drifts unless enforced |
| Team | One | iOS team + Android team |
| Fix a bug | Once | Twice |
| Deep platform features | Native modules bridge the gap | Unlimited, direct |
The cost math nobody runs past year one
The build quote is the visible half. Using the ranges I publish: a cross-platform MVP runs $5,000-$12,000 where dual native roughly doubles it. But the compounding cost is maintenance — every feature, every bug fix, every yearly OS-compliance update happens once or twice depending on this choice, forever. Two codebases also drift: the iOS app gets the feature first, Android "next sprint", and eighteen months later you effectively have two different products sharing a name.
Where native genuinely wins — and cross-platform sellers stay quiet
- Hardware companions: apps talking Bluetooth to devices all day. The bridge becomes your enemy.
- Continuous background work: always-on location, background audio pipelines — the platforms restrict this hard, and fighting through an abstraction multiplies the pain.
- Console-grade graphics and games: different tool class entirely.
- Single-platform-forever products: genuinely iPhone-only? A pure Swift build removes the abstraction for free.
If your app lives on that list, hire native specialists and pay the double bill with a clear conscience — it is cheaper than the rebuild after cross-platform fails you slowly.
The middle path most articles miss
Modern cross-platform is not either/or: a React Native app can contain native Swift or Kotlin modules for the specific 5% of the app that needs platform depth, while the other 95% stays shared. That is how "cross-platform can't do X" claims usually die in practice — the framework's own architecture is built for it. Shopify runs its mobile development this way at massive scale and wrote up why.
The decision, compressed
Standard product app — marketplace, booking, social, fintech UI, health tracking — with both stores on the roadmap: cross-platform, and spend the saved half on users. App whose core is hardware, background, or graphics: native, without guilt. Unsure which category you are in: that is a one-conversation question — and my cross-platform service page includes, in writing, an honest assessment when the answer is native.
⚠Mistakes to Avoid
- ✕Paying for two native teams before the idea has a single real user
- ✕Choosing cross-platform for a Bluetooth-heavy hardware app because it is cheaper upfront
- ✕Ignoring maintenance: the build is half the cost, parity-forever is the other half
- ✕Treating it as either/or when native modules cover the platform-deep 5%