Every app idea eventually collides with the same question: build it native, build it cross-platform, or ship a really good website and call it an app? The internet answers with loyalty to whichever tool the author last used. This guide tries something more useful — mapping each option's real tradeoffs onto the questions that actually determine success for small teams.
The three roads#
Native means Swift on iOS, Kotlin on Android (or their platform equivalents). Full access to every API and capability, best-in-class tooling, interfaces that match each platform's feel by default — at the price of writing, testing, and maintaining two applications.
Cross-platform frameworks — React Native, Flutter, Kotlin Multiplatform, and kin — write most logic once in one language and render UI either through native components or a self-drawn canvas. One codebase targeting both stores; the tax is an abstraction layer that occasionally leaks (platform updates arrive before framework support does) and a ceiling on how "native" anything feels.
Progressive Web Apps (PWAs) are websites with superpowers: installable to a home screen, offline-capable via service workers, push notifications where supported. Zero store review, instant updates, one URL — constrained by what browser engines expose, which still excludes some device APIs, deep background execution, and full shelf presence.
What actually differs between them#
| Dimension | Native | Cross-platform | PWA |
|---|---|---|---|
| Code reuse | ~0% | ~80–95% | 100% (it is web) |
| Device API depth | Complete | Broad, lagging edge cases | Browser-exposed subset |
| UI platform feel | Inherent | Good to excellent | Web-like |
| Distribution | Store review + 15–30% fee on digital sales | Same stores, same fees | No store; no fee |
| Update speed | Review-gated | Review-gated | Instant deploy |
| Hiring pool | Two specialist pools | Large shared pools | Largest (web devs) |
| Performance floor | Highest | High; rarely distinguishable | Fine for content/CRUD apps |
Two myths worth retiring: cross-platform is no longer meaningfully "slow" for typical app workloads — modern frameworks compile ahead-of-time or drive real native views; and PWAs are no longer toys — several classes of successful products are PWAs outright. Conversely, native-only capabilities (deep widgets, watch/companion apps, cutting-edge camera pipelines) remain native-only.
Five questions that decide it#
- What must the app touch? Bluetooth peripherals, advanced camera stacks, background sensor collection → native territory (or cross-platform with native escape hatches you're prepared to write). Content, forms, feeds, commerce, chat → any road works.
- Who's building it? A team of web developers ships a better PWA than a first native app. Existing React shops gravitate productively to React Native; design-heavy brands often prefer Flutter's pixel control.
- How do users return? Apps people open daily justify install friction and store presence. Occasional-use tools (calculators, reference sites, event pages) live happily as PWAs — installs would be abandonment anyway.
- Does revenue flow through the app? Stores take a cut of digital goods but handle payments, compliance, and discovery. Physical services and subscriptions have room to weigh the fees against alternatives.
- How fast must iteration be? Store reviews gate every release on the native/cross-platform roads; if your model demands same-day fixes, that friction compounds weekly.
Common patterns worth copying#
- Content, commerce, community → PWA first, adding a store wrapper only when retention data proves the install is earned. Many "apps" you use daily are this in disguise.
- Serious consumer products with rich interaction → cross-platform as default; one team, both stores, near-native result.
- Platform-deep products (camera, AR, wearables, performance-critical games) → native, accepting duplication as the cost of capability — possibly keeping shared business logic in a cross-platform core.
And note the exit ramps: starting PWA doesn't preclude wrapping later; starting cross-platform keeps native modules within reach. The expensive choice isn't picking wrong — it's building so much platform-specific surface that switching means rewriting.
The honest recommendation#
For a solo developer or small team validating an idea in 2026: web-first, installable, offline-capable gets you into users' hands in days rather than months, costs nothing per download, and teaches you whether demand exists before you've paid the store tax. Graduate upward only when a concrete limitation — an API you need, a distribution channel you want, performance you can't hit — names itself in production, not in imagination.
Choose based on what your app touches and how your users behave, not on which ecosystem's conference looked exciting last month. The platforms will all still be there when you need them.
Related: self-hosting vs serverless covers the backend half of shipping, and Core Web Vitals explains the speed budget a PWA lives inside.
