Native, cross-platform or PWA: choosing a mobile stack you won't regret
The mobile stack debate is usually argued on ideology and settled by regret. Here's the decision framework we actually use — including what on-device AI and the app stores change about the answer.
Few technical decisions generate more confident opinions and more quiet regret than the mobile stack. Teams pick native for performance they never needed, or a PWA for reach they never got, and discover the cost eighteen months in — when the switch means a rewrite.
We have shipped production apps in React Native, in Swift and Kotlin, and as installable web apps. None of them is the right default. The right answer falls out of a handful of questions about your product, your team and your distribution — and the honest version of those answers is usually less flattering than the one in the pitch deck.
Start from distribution, not technology
Before comparing frameworks, decide how the app reaches its users. If discovery happens through the app stores — consumers searching, installing, rating — you are building a store app, and the PWA conversation is mostly over before it starts. If your users are a known audience you can send a link to — employees, drivers, field teams, existing customers — the store is a distribution tax you may not need to pay.
The store also brings obligations people forget to price in: review cycles that turn a hotfix into a two-day wait, platform rules on payments and content, and a yearly ritual of SDK deadline compliance. A PWA sidesteps all of it; a store app has to budget for it. Neither is wrong, but choosing without acknowledging this is how teams end up surprised.
What the PWA honestly can and cannot do
The modern web platform is far more capable than its reputation — camera, geolocation, offline caching, installable icons, and on Android, push notifications that behave like native ones. For a booking flow, a customer portal, a data-entry tool for a known workforce, a well-built PWA ships faster, updates instantly and runs everywhere.
The ceiling is real, though, and it is mostly an iOS ceiling. Background processing is heavily restricted, deep hardware access (Bluetooth peripherals, NFC, precise background location) ranges from limited to absent, and the install experience remains a folk ritual users have to be taught. If your roadmap includes any of those, a PWA is a stopgap, not a destination — and it is cheaper to admit that now.
Cross-platform is the default for product apps — with eyes open
For most product companies, React Native (or an equivalent) is the pragmatic center: one team, one codebase, genuinely native UI, and 90% of the app — screens, navigation, forms, lists — is exactly the kind of code that shares perfectly. We build most client mobile work this way, and the economics are hard to argue with when you need both platforms and one team.
The costs are specific rather than vague. The remaining 10% — native modules, build tooling, upgrade cycles — requires someone on the team who is not afraid of Xcode and Gradle. Framework upgrades are a recurring project, not a version bump. And a genuinely demanding surface (real-time video processing, heavy animation, maps with thousands of live markers) will eventually push you into native code anyway — cross-platform means writing that part twice behind one interface, not never writing it.
When native is worth two codebases
Fully native still earns its cost in recognizable situations. The pattern they share: the platform itself is the product surface, not just the delivery mechanism.
If none of these describe your app, two native codebases mostly buy you two backlogs, two hiring pipelines and features that ship twice at different times.
- The app lives on hardware and sensors — BLE devices, OBD dongles, background tracking, camera pipelines — where every abstraction layer adds bugs
- Performance is the product: sustained 120fps interaction, heavy media, instant cold start as a competitive feature
- Deep OS integration — widgets, watch apps, platform-specific surfaces like CarPlay or Android Auto — is on the near-term roadmap
- You already have strong separate iOS and Android teams and the org can genuinely afford parallel delivery
On-device AI is quietly reshaping the calculus
A new consideration has entered the decision: where the models run. On-device inference — speech, vision, small language models — is now practical on recent phones, and it matters for latency, offline behavior and keeping sensitive data off the wire. The platform vendors are exposing this through native frameworks first, which strengthens the native and cross-platform cases and weakens the PWA one; browser access to the neural hardware is still early.
The practical takeaway is not 'go native for AI.' It is: if on-device inference is on your roadmap, make sure your stack has a clean path to native modules — which cross-platform frameworks do — and be skeptical that a pure web app will get you there this cycle. Cloud inference, of course, works identically from all three.
Decide like it's reversible in one direction only
Here is the asymmetry that should anchor the decision: moving up the capability ladder is a rewrite, moving down is wasted money. A PWA that outgrows the web must be rebuilt; a native app that never needed native has merely overpaid. So the question is not 'what is the best stack?' but 'what is the cheapest stack whose ceiling is comfortably above our three-year roadmap?'
Write the roadmap-driven requirements down — hardware access, offline depth, store distribution, on-device AI — and let them eliminate options before taste enters the room. In our experience the requirements usually leave exactly one sensible answer, and the teams that regret their stack are almost always the ones that skipped this step and argued frameworks instead.