"Should we build native or cross-platform?" is one of the first questions almost every founder asks when scoping a new app, and it's almost always framed as a technology decision. It isn't. Native, cross-platform, and progressive web apps are three different ways of answering the same underlying question: what does this app actually need to do, for whom, on what timeline, and with what budget for the next two to three years — not just launch day. Get the requirements right first, and the technology choice mostly falls into place on its own.
Native Apps: Swift and Kotlin
Native development means building two separate applications from the ground up: one written in Swift (or Objective-C) for iOS, one written in Kotlin (or Java) for Android. Each app uses its own platform's tools, compiler, and design conventions, and each is submitted, reviewed, and maintained separately. It's the oldest approach to mobile development, and for a specific category of app, it's still the only approach that makes sense.
Where native pays off
Native is the right call whenever an app's core value depends on squeezing the maximum possible performance and hardware access out of the device. It gives developers full, first-day access to every platform-specific API — camera controls, ARKit or ARCore, Bluetooth Low Energy, biometric sensors, background processing limits, haptics — without waiting for a third-party framework to catch up. That makes native the correct default for camera-first apps, augmented-reality experiences, apps pairing with Bluetooth hardware or wearables, high-end games with custom rendering pipelines, and anything doing real-time on-device processing such as live video effects or complex sensor fusion. If the app's differentiator is what it does with the hardware, native removes every layer of abstraction between your code and the device.
The tradeoff: two codebases, two budgets
The cost of that ceiling is that you are now building and maintaining two products, not one. Every feature gets designed, built, tested, and shipped twice — once in Swift, once in Kotlin — by developers who typically don't overlap in skill set, so you're effectively running two engineering tracks under one product roadmap. That roughly doubles both the initial build cost and, more importantly, the ongoing maintenance cost: every bug fix, every OS update, every new feature request happens twice. Feature parity between iOS and Android stops being automatic and becomes a project-management problem in its own right, and it's the compounding cost over years two and three — not the launch bill — that catches most teams off guard.
Cross-Platform: React Native and Flutter
Cross-platform frameworks — React Native and Flutter are the two dominant choices in 2026 — let a single codebase compile down to genuinely native iOS and Android apps rather than a wrapped web view. The app still gets installed from the App Store and Play Store, still uses native UI components, and for the large majority of business apps, performs close enough to native that end users can't tell the difference.
Where cross-platform wins
A single codebase means one team builds one product that ships to both platforms, which cuts both development cost and time to market substantially compared with maintaining two native codebases in parallel. Bug fixes and new features ship once and reach both platforms simultaneously. For the categories of app most businesses actually build — content apps, booking and reservation tools, e-commerce and marketplace apps, service and delivery apps, internal operations dashboards — cross-platform performance is, in practice, indistinguishable from native. Neither React Native nor Flutter is asking you to trade away quality; they're asking you to trade away the narrow slice of apps that genuinely need hardware-level native access.
The tradeoff: native modules and day-one lag
Some platform-specific features still require a native module — a small bridge of platform-specific code — to work at all, which reintroduces a bit of the two-codebase problem for those specific features even inside an otherwise shared app. And when Apple or Google ship a brand-new OS-level capability on day one of a new OS release, cross-platform frameworks typically need a few weeks to a few months to catch up with their own wrapper. For most product roadmaps, that lag is irrelevant, because bleeding-edge, day-one OS features are rarely what the app is actually built around.
Progressive Web Apps (PWA)
A PWA is a website engineered to behave like an app: installable to a home screen, capable of working offline through cached data, and in some cases able to send push notifications — all while remaining, underneath, a single website codebase that runs in the browser. There's no separate iOS or Android build at all; there's one web app that adapts to whichever device opens it.
Where a PWA wins
A PWA skips the app store approval process entirely, so there's no review wait, no rejection risk, and no update cycle gated by Apple or Google — you ship a change and every user has it the next time they open the page. One codebase covers every device with a browser, including desktops, which native and cross-platform apps don't reach at all. That makes a PWA the strongest option for content and informational products — blogs, news and media, product catalogs, lightweight booking tools, internal company tools — where the goal is fast, frictionless access rather than deep device integration.
The tradeoff: limited hardware access and no store presence
PWAs have meaningfully restricted access to native device APIs: deep Bluetooth integration, full biometric authentication, and background processing are either limited or unavailable depending on the platform. They also have zero presence in the App Store or Play Store, which removes an entire discovery and trust channel — no store search visibility, no star ratings, no "featured app" placement. And support has historically been uneven: Apple has been slower than Android to fully support PWA capabilities like push notifications and generous offline storage, so a feature that works reliably for an Android visitor may behave differently for an iOS visitor on the very same PWA.
Comparing the Three Head-to-Head
Laid side by side, the tradeoffs are consistent: native buys a performance and hardware ceiling that cross-platform and PWA can't match, at a cost and timeline that scale with every platform supported.
| Native | Cross-Platform | PWA | |
|---|---|---|---|
| Development cost | Highest — two codebases, two teams | Moderate — one codebase, one team | Lowest — one lightweight web codebase |
| Time to market | Slowest | Faster | Fastest |
| Performance ceiling | Highest possible | Near-native for most business apps | Good for content, limited for hardware-heavy tasks |
| App store presence | Full — App Store & Play Store | Full — App Store & Play Store | None — installed from the browser |
| Best for | Camera/AR/Bluetooth-heavy apps, high-end games | Most business apps: booking, e-commerce, service, dashboards | Content, informational, catalog-style products |
Start From the Requirements, Not the Technology
Once the three approaches are on the table, the actual decision comes down to four questions that have nothing to do with which framework is fashionable this year. What hardware, if any, does the app genuinely need to touch — camera, sensors, Bluetooth, biometrics — and how deep does that access need to go? Who is the audience, and do they expect to find the app by browsing a store, or would they use it just as readily from a link? What's the realistic engineering budget across the next 24 months, not just the launch invoice? And how fast does the product need to be in front of real users to start learning from them?
List every hardware capability the app truly needs on one line. If that line is empty or short — no camera, no Bluetooth, no offline GPS tracking — cross-platform or even a PWA is very likely enough, and native is solving a problem the product doesn't have.
Choosing native "to be safe" for a first version that only needs to validate whether people want the product at all. Building two native codebases for an unproven idea burns months and budget that should have gone into iteration after launch — and if the idea needs to pivot, there's now twice as much code to rework.
A Five-Step Decision Framework
Use this order when scoping a new app, and resist the urge to start from a technology you already like:
- 1Start from hardware requirements, not preference.
List exactly which native APIs the app depends on. If the honest list is short, you've already ruled out needing native by default.
- 2Map the real audience and discovery channel.
Decide whether users need to find the app by browsing a store, or whether a shared link or QR code is a realistic way for them to arrive.
- 3Budget for 24 months, not launch day.
Price out year-two maintenance under each approach before committing — that's usually where native's true cost shows up, not the initial build quote.
- 4Match the approach to your validation stage.
An unproven idea needs to ship fast and iterate; a scaled, funded product with proven demand can justify a heavier native investment where it earns its keep.
- 5Build with a migration path in mind.
Isolate any hardware-specific code behind a clean interface layer from day one, so moving from cross-platform to a native module later — or vice versa — is a targeted change, not a rewrite.
Frequently Asked Questions
Yes, and it's a common, sensible path. Most teams launch on React Native or Flutter, validate demand, and then rebuild only the specific screens or features that genuinely need native-level performance — rather than rewriting the whole app. A clean architecture from day one makes this a targeted upgrade instead of a full rebuild.
For lightweight or catalog-style e-commerce, yes. For e-commerce that depends on saved payment methods, push notifications for cart abandonment, or deep integration with device wallets, a cross-platform app usually performs better, since PWA support for those features is still inconsistent on iOS.
For the large majority of first apps, we recommend cross-platform development with React Native or Flutter. It gets a real, store-published product in front of users faster and cheaper than native, while still leaving room to add native modules later for any feature that genuinely needs them.
For the kinds of apps most businesses build — content, booking, e-commerce, service, and dashboard apps — no. Modern cross-platform frameworks render with native UI components and are close enough in performance that end users don't notice a difference. The gap only becomes noticeable in graphics-intensive apps like high-end games or apps doing heavy real-time processing.
Because native requires two separate codebases built and maintained by two skill sets, it typically runs close to double the cost of a comparable cross-platform build — and that gap compounds every year afterward, since every future feature and bug fix also gets built twice.
If your product is primarily informational or content-based and doesn't depend on deep hardware access or app store discovery, a PWA can be genuinely enough — and it's the fastest, cheapest way to find out before committing to a full native or cross-platform build.
Key Takeaways
- The native-vs-cross-platform-vs-PWA decision is a business-requirements question, not a technology preference — start from what the app needs to do, not from what's fashionable.
- Native (Swift/Kotlin) wins on raw performance and full hardware access, but doubles development and maintenance cost by requiring two separate codebases.
- Cross-platform (React Native/Flutter) delivers near-native performance for most business apps from a single codebase, at meaningfully lower cost and faster time to market.
- PWAs skip app store approval entirely and reach every device from one web codebase, but trade away deep hardware access and store discoverability.
- Choosing native "to be safe" for an unproven MVP is one of the most common — and most expensive — mistakes founders make.
- Most first apps are best served by cross-platform development, with a clear path to add native modules later if specific features genuinely need them.
