Do you need a mobile app, or would a PWA do? A 2026 decision guide

"We need a mobile app" is one of the most expensive sentences a company can say without examining it. It commits you to a separate codebase, two app-store accounts, a review process, and an ongoing maintenance stream — before anyone has asked whether a progressive web app would have done the same job for a fraction of the budget. Sometimes a native app is exactly right. Often it isn't. This guide is the decision you should make before the framework decision: app, or PWA?

What a PWA actually is

A progressive web app is a website built so it behaves like an installed app. The user adds it to their home screen; it opens full-screen with its own icon, no browser chrome; a service worker caches it so it loads instantly and works offline; and it can send push notifications. That last point is where most outdated advice goes wrong — web push has worked for installed PWAs on iOS since iOS 16.4, not just on Android. A modern PWA is much closer to a native app than the 2019 version was.

The decisive advantages are cost and reach. A PWA is one codebase — frequently the same codebase as your website — so you build and maintain one thing, not three. There is no app-store account, no submission, no review wait, and no 15–30% store commission on anything you sell. And it's a URL: you can link to it, a search engine can index it, and an update is live the moment you deploy, with nothing to approve.

What only a native app can do

A PWA is not a native app, and the gap, though narrower every year, is real. A native app is worth its higher cost when the product genuinely needs one of these:

• Deep device integration · tight access to hardware and OS features — advanced camera control, Bluetooth peripherals, health and sensor data, widgets, deep OS-level integrations. A PWA's access here is improving but still partial.
• Heavy graphics or compute · games, AR, real-time video processing, on-device machine learning at scale. A native app has the performance headroom a PWA does not.
• Sustained background work · reliable background processing, geofencing, precise long-running location tracking. PWAs are deliberately limited here.
• App-store discovery as a channel · if a meaningful share of your users will find you by searching the App Store or Google Play, a PWA simply isn't in that index. For a consumer product this can be the deciding factor.
• Platform trust signals · in some markets and sectors, "it's on the App Store" is itself a credibility cue your audience expects.

The honest cost difference

A PWA shares its codebase with your web product, so the marginal cost of the "app" is small — service worker, install prompt, offline strategy, push. A native app, even built cross-platform with React Native or Flutter, is a separate product: its own build, its own release pipeline, store accounts and fees, a review cycle on every update, and a permanent maintenance stream because every iOS and Android version can break something. That maintenance stream is the cost most teams forget to price — a native app is never "done."

The distribution question

This is the fork that decides more cases than capability does. A PWA is distributed the way a website is: a link, a QR code, an entry in search results, a row in your email. You own the channel and the relationship. A native app is distributed through the App Store and Google Play: you get their discovery surface and their trust halo, but you also get their review process, their policies, their commission, and their power to delay or reject an update. Ask honestly: will your users find this by browsing an app store, or will you bring them to it yourself? If it's the latter, the store is overhead, not a channel.

A decision checklist

Work down this list. If you answer "yes" to one of the native questions and mean it, a native app is probably justified. If not, a PWA likely does the job for less.

1. Does the product need hardware or OS access a PWA can't reach today? · If yes, lean native.
2. Is it graphics- or compute-heavy — a game, AR, real-time media? · If yes, lean native.
3. Does it need reliable background processing or precise location tracking? · If yes, lean native.
4. Will app-store search be a real acquisition channel for you? · If yes, lean native.
5. Is none of the above true, and is speed-to-market or budget a constraint? · Then a PWA is very likely the right call.

The hybrid path

It is rarely a permanent either/or. A sound, low-risk path for many products: ship a PWA first. It's the fastest way to get a real product in front of real users, it costs the least, and it tells you whether the demand is there. If usage proves out and a concrete native-only need appears — store discovery matters more than expected, or a feature genuinely requires deep device access — you build the native app then, with real usage data to scope it. You spent the native budget on a validated product instead of a guess.

How DField Solutions approaches it

We build both, so the recommendation isn't pre-decided by what we'd rather sell. On a scoping call we work through the checklist above with you: if a PWA covers the need, we'll say so and save you the native budget; if the product genuinely needs a native app, we build it cross-platform with React Native or Flutter and handle the store submission end to end. Either way you own the code, and either way the decision is made on your product's needs, not our preference.

If you're weighing a mobile build, the mobile service page covers how we work, and a 30-minute discovery call is the fastest way to run the app-vs-PWA decision against your actual product. The glossary has a plain-language entry on PWAs and the related terms.