Do You Really Need a Mobile App? Maybe a PWA Is Enough

Before you spend a fortune building separate iOS and Android apps, it is worth asking an honest question: do your customers actually need to download anything? A lot of the time, the answer is no, and a Progressive Web App does the job for a fraction of the cost.

A PWA is basically a website that behaves like an app. It loads fast, works offline, can send push notifications, and users can add it to their home screen. No app store listing, no waiting days for approval just to fix a typo. And because it is one codebase that runs everywhere, you are not paying to build and maintain the same thing twice.

That does not make a PWA the right choice every time. Below is the framework we use to decide before anyone writes a line of code. Answer these five questions honestly and the answer usually picks itself.

Question 1: How often will people use it?

Frequency is the biggest single factor. People happily install apps they open every day: banking, messaging, ride-hailing, food delivery. They will not install one for something they do twice a year. Asking a customer to open a store, search, download a sizeable file and create an account before they can book a service is a lot of friction for an occasional task.

Leans PWA: occasional use, first-time visitors, anything people find through search or a shared link. Leans native: daily or near-daily habits where a home-screen icon earns its spot.

Question 2: Which device features do you truly need?

Modern browsers can do a lot: camera access, location, offline storage, push notifications, payments. Native still clearly wins for heavy graphics and games, continuous background work such as tracking location while the phone is locked, deep Bluetooth or NFC work with hardware, and tight integration with things like health data or home-screen widgets. Web feature support on iPhones has also historically lagged behind Android, so check each feature you depend on, on the devices your customers actually carry.

Leans PWA: forms, catalogues, booking, dashboards, content, internal tools. Leans native: anything where a core feature only exists in native APIs.

Question 3: Do you need to be found in the app stores?

Some audiences genuinely search the App Store or Play Store first, and in some categories a store listing builds trust. For most businesses, though, customers arrive through Google, social media, ads or a link someone shared. A PWA is a website, so search engines can index it and anyone can share it as a normal URL, which an in-app screen cannot match. If discovery mostly happens on the web, a store presence adds cost without adding customers.

Question 4: How fast do you need to ship and change things?

With a PWA, you deploy an update and every user has it the next time they open it. With native apps, each release goes through store review, and then you wait for users to update, which some never do. That means supporting old versions longer than you would like. If your pricing, menu or promotions change weekly, or you are still finding out whether the product works at all, that speed matters a lot.

Question 5: What is your real budget, including year two?

Two native apps usually mean two codebases (or one cross-platform codebase with platform-specific fixes), developer accounts, store compliance work and testing on many devices. The build is only the start: every major OS update can break something. A PWA is one product to maintain. As a general market pattern, going native on both platforms costs noticeably more than a comparable PWA, and the gap tends to widen over years of maintenance.

About that app-store cut: Apple and Google take a commission on digital goods and subscriptions sold inside apps. If you sell physical products or real-world services, that rule generally does not apply, so for a shop or a booking business it should not be the deciding factor. Maintenance cost and release speed matter more.

Adding it up

If most of your answers were "occasional use, standard features, found via the web, need to change things often, limited budget", build a PWA. If they were "daily habit, needs device hardware, store discovery matters, stable feature set, budget for two platforms", native is justified. Mixed answers are common, and that is where the middle options come in.

The middle options

• PWA first, native later. Launch the PWA, learn what people actually use, then build a native app for your most loyal users if the numbers justify it. You will write a far better app spec after months of real usage data.
• Cross-platform native. Frameworks such as Flutter or React Native produce real store apps from one codebase. They usually cost less than two separate native builds while keeping store presence and most device access. Our Android and iOS app development team often recommends this route when native is genuinely needed.
• Just a good responsive website. Sometimes you do not need app behaviour at all. If people mainly browse and buy, a fast ecommerce website may be all the "app" your customers want.

Mistakes we see on both sides

• Building an app because a competitor has one, without checking whether their customers actually use it.
• Treating a PWA as "just a website" and skipping offline handling, install prompts and performance work, so it ends up feeling like neither.
• Forgetting that someone has to keep it running. Budget for maintenance from day one, whichever route you pick.
• Testing only on the team's flagship phones instead of the cheaper, older devices many customers really use.

So the real question is not "web or app," it is "what do my customers actually do?" If you are not sure, we are happy to talk it through honestly before anyone writes code, even when the honest answer turns out to be native. Here is our Progressive Web App development service if you want app-like results without the app-store baggage.