Native, cross‑platform or web app: how to choose
Three ways to build a mobile app, each with different costs and limits. A plain-language comparison and a set of questions to help you choose.
- Published
- Reading time
- 5 min
Choose native development when the app depends on demanding device features or performance, a cross-platform framework when you need iOS and Android from one codebase, and a progressive web app when reach and speed of release matter more than app-store presence. For most business apps, cross-platform is a sensible default.
The decision affects cost, time to first release and what the app can do for years afterwards. It is also hard to reverse. Here are the three routes, their trade-offs and the questions that lead to a choice.
Native, cross-platform and PWA in plain language
Native apps
A native app is built separately for each platform with the tools its maker provides — typically Swift for Apple’s iOS and Kotlin for Google’s Android. The result is two apps and two codebases, each with full access to what the device and operating system offer.
Cross-platform apps
A cross-platform app is written once and released on both platforms. React Native and Flutter are two widely used frameworks. They work differently: React Native builds on the platform’s own interface components, while Flutter draws the interface itself. Either way, users get a real app installed from the App Store or Google Play.
Progressive web apps
A progressive web app, or PWA, is a website built to behave like an app. It opens in the browser, can be added to the home screen and can keep working on a poor connection. Nothing is downloaded from a store, and one version serves phones, tablets and computers.
Native vs cross-platform vs PWA: the trade-offs compared
No column wins every row. The right choice depends on which rows matter most to your product.
Device features and performance: where the routes differ
Native apps have the most direct access to the device: camera, sensors, Bluetooth, payments, background processing, widgets and companion apps for watches. When Apple or Google introduce something new, native developers can use it first.
Cross-platform frameworks reach most of these features through ready-made components. Where none exists, developers write a native part for each platform and connect it to the shared code. A cross-platform project is therefore rarely free of native code altogether.
PWAs work within what the browser allows. Camera, location and offline use are generally available. Bluetooth, NFC, background activity and notifications vary by browser and platform, and support on iPhone has generally been narrower than on Android. Check the current position for every feature your product relies on.
On performance, the gap is smaller than the debate suggests. Lists, forms, bookings and accounts run well on all three routes. Native has a clear advantage for demanding graphics, real-time audio or video processing and augmented reality.
Business apps are more often held back by unclear design or a slow backend than by the choice of framework.
One codebase or two: cost, time and maintenance
Two native apps mean two sets of code and every feature built and tested twice. That is the main reason native costs more when you need both platforms. If you need only one, the argument weakens considerably.
A shared codebase reduces the duplication, but not to zero. Each platform still needs its own testing, store preparation and occasional adjustments. You also depend on the framework: it has to be kept up to date, and new operating-system versions sometimes require work before the app behaves correctly again.
A PWA is usually the quickest to release, because it is a web application and needs no store review. Updates reach users as soon as they are published. If you already plan a web platform, part of the work is shared — see what drives website cost.
Whichever route you take, plan for life after launch. Operating systems change every year, and an unmaintained app gradually stops working as intended.
App-store presence: when it matters
A listing in the App Store and Google Play puts you where people look for apps. It also brings review processes, guidelines and rules for selling digital goods inside the app. These rules differ between stores and regions, and they change.
A PWA is not listed in the stores by default. It can be packaged for Google Play, while Apple expects an app to offer more than a repackaged website. If customers expect to find you in the stores, a PWA alone is unlikely to be enough.
A PWA has a different strength: it can be found through search engines and opened from a link, with nothing to install. For a service people use occasionally, that lower threshold can matter more than a store listing.
Questions to ask before choosing a mobile app technology
- Which device features does the first version need, and which might later versions need?
- Do your users expect to find you in the app stores?
- How often will people use it: daily, or a few times a year?
- Do you need iOS and Android at launch, or does one platform cover most of your audience?
- Does the app have to work without a connection?
- Who will maintain it in three years, and with which skills?
An internal tool for a field team and a consumer product for the public can need opposite answers. Where the app is one part of a larger system, the backend and integrations often deserve more attention than the app itself, which is custom software work.
A recommendation pattern: if this, then that
- If the product depends on demanding graphics, advanced camera or sensor work, or the newest operating-system features, then build native.
- If you need both platforms, a store presence and standard features such as accounts, content, bookings, payments and notifications, then choose a cross-platform framework.
- If your audience uses one platform almost exclusively, then a single native app can be simpler than a framework.
- If the service is used occasionally, must open from a link and needs few device features, then start with a progressive web app.
- If you are still testing whether people want the product, then take the route that reaches real users soonest, and accept that you may rebuild later.
These are starting points, not rules. A short technical assessment before development begins costs far less than changing route halfway. To talk through your case, see our mobile applications service or start a conversation.
FAQs
Questions people ask.
Usually, when you need both iOS and Android, because most of the code is written once. If you need only one platform the difference is small, and a project with many platform-specific features can lose much of the saving.
Not by default. A PWA can be packaged for Google Play, while Apple expects apps to offer more than a repackaged website, so approval there is not guaranteed.
Yes. Both produce apps that are installed from the App Store and Google Play and can use device features. Users generally cannot tell which technology was used.
Yes, but it is largely a rebuild of the app itself. The backend, the design and what you have learned about your users carry over, which is often a large part of the work.
Related serviceMobile applications
Explore the service
