Most app projects fail on scope, not code. The founder wants "an app"; the agency is happy to build one; twelve weeks and a large invoice later there is an app in two stores that does what the website could have done for a third of the money, with none of the app-store review pain. The question that should have been asked first is: what does this product need to do that a browser cannot?
Three things you can build
- A responsive website. Works everywhere, one codebase, indexed by search engines, instant to update. Cannot install, work offline, or reach most device hardware.
- A progressive web app (PWA). A website with a service worker and a manifest: installable to the home screen, full-screen, cacheable for offline use, fast. Still one codebase, still indexable, still no app store. Limited (but growing) access to hardware and notifications.
- A native or cross-platform app. Built for iOS and Android — either separately in Swift and Kotlin or once in React Native or Flutter — and distributed through the stores. Full access to the device, the best performance ceiling, and the most expensive to build, ship and maintain.
What genuinely needs an app
These are the capabilities where the browser either cannot do it or does it too unreliably to build a business on. If your product depends on one of them, you need an app.
- Reliable push notifications, especially on iOS. PWAs can send push on iOS since 16.4, but only after installation to the home screen, and with more friction and fewer guarantees than native. If re-engagement by notification is the product's engine, go native or cross-platform.
- Background work. Location tracking while the app is closed, background sync, uploads that continue when the screen is off, audio playback in the background. Browsers deliberately restrict this.
- Deep hardware access. Bluetooth peripherals, NFC payments, advanced camera control, sensors beyond the basics, health data, secure enclaves for biometrics beyond simple unlock.
- App-store distribution as a channel. If a meaningful share of your customers will find you by searching the App Store or Google Play, or if being "in the store" is a trust signal in your market, presence there is a feature in itself.
- Sustained high-performance graphics or compute. Games, AR, real-time video processing. Browsers are improving, but native still wins by a wide margin.
- OS integration. Widgets, Siri and Google Assistant shortcuts, share-sheet targets, watch companions, CarPlay and Android Auto.
What a PWA covers perfectly well
And these are the things people commonly build apps for that a PWA handles at a fraction of the cost.
- Browsing a catalogue and buying — with a cart that survives offline and a checkout that works.
- Booking, scheduling and account management — appointments, orders, invoices, profile settings.
- Dashboards and reporting for internal or customer use.
- Content and community — articles, courses, forums, member areas.
- Forms and field data capture that need to work with poor connectivity and sync later.
- Loyalty and membership cards — a home-screen icon that opens to a QR code.
- Camera capture, basic geolocation and web payments — all available to the browser today.
A PWA also keeps the one thing an app gives up: search visibility. Every screen is a URL Google can index and someone can share. For a business that acquires customers through search, putting the product behind an app-store download is an expensive way to become invisible.
The decision framework
Work through these in order and stop at the first that decides it.
- List the capabilities the product cannot function without. Not nice-to-haves — the ones where, if a browser cannot do it, there is no product. Check each against the "genuinely needs an app" list above. One genuine hit means an app; none means a PWA is the default.
- Who are the users and how do they arrive? Found through search or links → the web is your distribution, favour a PWA. Recruited through the app stores or enterprise deployment → an app fits the channel.
- How often will they use it? Daily use with notifications benefits from an app's presence and reliability. Weekly or occasional use rarely justifies a download; the install friction loses more users than the app gains.
- Is the audience mostly iOS? iOS is where PWA limitations bite hardest — push, install prompts, some APIs. A predominantly iPhone audience nudges toward native or cross-platform for anything notification-driven.
- What is the budget for year two? An app is two store listings, OS updates twice a year, review cycles, and device fragmentation. If year two's maintenance budget is not there, do not build year one.
- Could you start with a PWA and add an app later? Very often yes. Validate demand and learn what users actually do on the web; then build the app around the features that proved to need it. Many successful products went in this order, and a well-built PWA can be wrapped in a native shell later to gain store presence cheaply.
Rough cost and time comparison
| PWA | Cross-platform app (React Native / Flutter) | Two native apps | |
|---|---|---|---|
| Codebases | 1 (shared with website) | 1 (+ native modules) | 2 |
| Time to first release | 4–8 weeks | 10–16 weeks | 14–24 weeks |
| Relative build cost | 1× | 2–3× | 3–5× |
| Store review | None | Both stores | Both stores |
| Search visibility | Full | None (store listing only) | None |
| Push on iOS | After install, limited | Full | Full |
| Hardware access | Basic | Near-full | Full |
The ratios are what matter, not the absolute numbers; every product is different. The pattern is consistent: the app costs two to five times as much and removes you from search, so it has to earn that with capabilities the browser cannot provide.
If you do build an app
- Choose React Native or Flutter unless a specific requirement demands native — one codebase for both platforms is the right default for most products.
- Treat cold-start time, bundle size and battery use as launch requirements and test on real mid-range devices from the first sprint.
- Keep a web presence for acquisition: landing pages that rank and explain, with deep links into the app.
- Plan for the store review — first-time Apple rejections are common and should be in the schedule, not a surprise.
- Own everything: developer accounts, signing keys and source code in your name from day one.
Build an app when the product depends on something a browser genuinely cannot do. Build a PWA when it does not. Deciding this honestly before the first sprint is worth more than any technology choice made after it.
This is the first conversation in every mobile project we scope, and it regularly ends with a smaller quote than the client expected — sometimes for a fast web build instead of an app at all. The scoping document is yours either way.
Frequently asked questions
What is a progressive web app (PWA)?
A website built to behave like an app: installable to the home screen, able to work offline or on poor connections through a service worker, fast, and full-screen without browser chrome. It is delivered through the browser, so there is no app-store submission, one codebase serves every device, and updates are instant.
Can a PWA send push notifications on iPhone?
Yes, since iOS 16.4 — but only after the user has added the PWA to their home screen, and with less reliability and fewer options than a native app. If push notifications are central to the product and most users are on iOS, that limitation usually tips the decision toward a native or cross-platform app.
How much cheaper is a PWA than a native app?
Typically a third to a half of the cost of building and maintaining separate iOS and Android apps, because it is one codebase, shares most of its code with the website, and needs no store submissions or review cycles. The saving shrinks if the product needs deep hardware access that must be reimplemented natively anyway.
