Mobile App or Progressive Web App? How to Decide Honestly
Most businesses asking for an app need a fast website. Some genuinely need the store. Here is the short list of things that actually force the decision, and what each choice costs you afterwards.
A good proportion of the people who ask us to build a mobile app do not need one. They need a website that is fast on a phone, and they have been told for a decade that a business needs an app.
Some genuinely do need the store. The difference is not a matter of taste, and it is not about which technology is more modern. It comes down to a fairly short list of capabilities and one question about how people will find you.
What actually forces a native build
If your product needs any of these, the decision is made and the rest of this article is background reading.
Background execution. Anything that must run while the app is closed — location tracking for a delivery driver, continuous health monitoring, syncing large amounts of data on a schedule. Web apps do not get to run in the background in any dependable way.
Reliable push on iOS. Notifications are also a channel that is easy to spend badly — see push notifications people do not turn off. Web push works on iOS, but only for an app the user has explicitly added to their home screen, and the reliability is not comparable. If notifications are core to the product rather than a nice extra, that is a native requirement.
Deep hardware access. Bluetooth peripherals, NFC, biometric authentication tied to a secure enclave, camera control beyond taking a photo, background audio. Some of this has web equivalents; most of it is either partial or absent on iOS.
Store distribution as the business model, which brings review with it — worth reading why apps get rejected before you commit. If people find products by browsing an app store, or you need in-app purchase billing, you need to be in the store. This is a distribution argument, not a technical one, and it is a perfectly good reason.
Performance at the edge of what a phone can do. Heavy graphics, real-time video processing, large local datasets. Ordinary business software is nowhere near this line.
If none of those apply, keep reading, because the default answer is probably the web.
What forces the web
You need to be found in search. This is the big one and it is routinely underweighted. A native app's content does not exist as far as Google is concerned. Every page of a web app can rank, can be linked to, and can be shared as a URL that opens instantly. For most businesses, search and sharing are the main way strangers arrive.
One link has to work for everyone. Sending a URL to a customer and having it open is worth more than most feature lists. No install, no store account, no fifty-megabyte download on a poor connection.
You need to ship changes quickly. A web deploy is live in minutes. A native release goes through review, then waits for people to update. When something is wrong in production, that difference is the whole game.
Budget is genuinely tight. Our breakdown of what drives mobile app cost covers where the money actually goes. Two native platforms means either two codebases or one cross-platform codebase plus platform-specific work at the edges. Either way it is meaningfully more than one well-built responsive web app.
The honest middle
The comparison people expect is native versus web. In practice the useful spectrum has four points:
A responsive website. Not an app at all. For most brochure, booking, catalogue and content businesses, this is the correct answer and the money saved is better spent on the content and the marketing.
A progressive web app. A website that installs to the home screen, works offline for the parts you have cached, and can send push on Android. Good for tools people return to daily — dashboards, internal systems, order entry.
A cross-platform native app. Flutter or React Native. One codebase, both stores, near-native performance, full hardware access. The right answer when you genuinely need the store or the hardware, which is more often than the web maximalists admit.
Two fully native apps. Swift and Kotlin, separately. Reserved for products where the app is the business and platform-specific polish is a competitive advantage.
Most projects that think they are at point four belong at point two or three.
The costs nobody mentions
Native has a permanent tax. Two app stores with review processes, SDK deprecations every year, OS releases that break things each autumn, and users on versions from three years ago. A native app is not a project that finishes; it is a commitment to ongoing maintenance. Budget for it or the app quietly rots.
PWAs have an iOS asterisk. Installation is a share-sheet step most people will never find unless you tell them. Storage can be reclaimed by the system if the app goes unused for long enough. Neither is fatal, both are real, and any agency that does not mention them is selling rather than advising.
Two codebases double more than the code. Testing, releases, bug triage, analytics, support. The multiplier lands on everything around the code, not just the code.
How to decide in ten minutes
Run down the native-forcing list. If nothing applies, build for the web and revisit in six months with actual usage data rather than assumptions.
If something does apply, ask whether it applies to your core flow or to one feature. A single feature needing the camera does not justify a native app; it justifies a file upload that works well on mobile.
And if the honest answer is that you want an app because competitors have one — that is a marketing decision wearing an engineering costume. Sometimes it is still the right call. It just should not be argued on technical grounds, because it will lose.
What we usually recommend
For most businesses that come to us describing an app: a fast, well-structured web app first, designed so the API would serve a mobile client later. Ship it, watch what people actually do, then decide about the store with evidence instead of a hunch.
That advice costs us the larger project more often than not. It also means that when we do say you need to be in the store, it is worth something.
If you are weighing this up and want a straight answer for your specific case, tell us what you are building.