Short answer: choose a PWA when people reach you through links and search, use the product occasionally, and you do not depend on store discovery, store billing or deep device access. Choose a store app when the product is a daily habit, when notifications on iPhone are central, when you sell through in-app purchases, or when you need hardware and background features browsers do not expose. If you have a good web app and need the stores as well, wrap it with Capacitor and keep one codebase.
Terms. In this article “native app” means any app installed from the App Store or Google Play, which is how most founders use the phrase. Whether that store app should be written in Swift and Kotlin, in React Native or as a hybrid is a separate question, answered in our native vs cross-platform decision guide.
What a PWA is
A progressive web app is a website with three additions: a manifest file that tells the device its name, icon and how to open it; a service worker, which is a script that can cache files and respond when there is no network; and delivery over HTTPS. With those in place a browser can install the site to the home screen, open it without browser controls, and keep it working offline to whatever extent you have built for.
There is no store review, no store commission and nothing to download beyond the page itself. Updates reach every user the next time they open the app.
What a PWA can do today
| Capability | Android (Chrome and similar) | iPhone and iPad (Safari) |
|---|---|---|
| Install to home screen | Yes, and the browser can show an install prompt that your interface can trigger | Yes, but manually through Share, then Add to Home Screen. No automatic prompt, so you have to explain it |
| Full-screen, app-like window | Yes | Yes, once installed |
| Offline use | Yes, through a service worker and local storage | Yes, through the same mechanism |
| Push notifications | Yes | Yes since iOS 16.4, only for web apps added to the Home Screen and only after a permission request triggered by the user |
| Camera and photo upload, geolocation while open, share sheet, clipboard | Yes | Yes, for the common cases |
| Payments for physical goods and services | Yes, through any web payment provider | Yes |
| Background sync, periodic background tasks | Partly, in Chromium-based browsers | Very limited |
| Bluetooth, NFC, USB | Partly, through web APIs in Chromium-based browsers | Not available in Safari |
| Listing in the store | Possible on Google Play by packaging the PWA as a Trusted Web Activity | Not as a PWA; requires an app package |
Browser support moves, in both directions. Treat the table as a starting point and test the specific feature you depend on, on current OS versions, before committing to a plan that relies on it.
What a PWA cannot do, or does poorly
- Be found in the App Store. For consumer products, many people look for an app by searching the store. A PWA is invisible there on iOS, and on Android only appears if you package and submit it.
- Use store billing. A PWA cannot sell through Apple or Google in-app purchase. That is an advantage if you would rather take payment on the web and keep the commission, and a drawback if you want the one-tap purchase that store billing gives.
- Run reliably in the background. Continuous location tracking, long uploads after the app is closed, scheduled local alarms and similar behaviour are either unavailable or restricted.
- Reach deep into the device. Widgets, watch apps, health data, contacts and calendar access, advanced camera control, and on iOS Bluetooth and NFC, are outside what browsers offer.
- Guarantee storage. Browsers can clear a site's stored data when the device is short of space or the app has gone unused for a long time. Treat on-device data as a cache of something held on a server, not as the only copy.
- Install easily on iPhone. The manual steps cost you a share of users, and with them the ability to send those users notifications.
- Carry paid install campaigns. Mobile ad networks and attribution tools are built around store installs.
What a store app gives you
- Presence and search visibility in the App Store and Google Play, with ratings and reviews that act as social proof.
- Push notifications that work the same way for every user after one permission dialog.
- In-app purchases and subscriptions with the payment method the user already has on file. The rules and commission are explained in our guide to app monetization models.
- Full access to device features, background work within each platform's rules, and local notifications.
- Durable on-device storage.
The price is store review and policy compliance, release work for every update, annual OS changes to keep up with, and commission on digital sales. Our Google Play release checklist shows what the Android side of that involves.
The hybrid route: web code inside a store app
You do not have to choose between web technology and the stores. Capacitor packages a web application as a real iOS and Android app. The interface is still your HTML, CSS and JavaScript running in the system web view, while plugins give it native push and local notifications, in-app purchases, ads, the file system and other device features. The result is submitted to the stores like any other app.
Both of BBR's published Android apps are built this way. Grow.io is an HTML5 canvas game with AdMob ads and Google Play Billing purchases. Live Gold & Silver Prices is a data app whose price alarms are delivered as local notifications, which is exactly the kind of feature a PWA cannot provide dependably. In both cases the same code runs in a desktop browser during development.
The route has limits too. Interfaces that depend on very long, fast lists or intricate gestures take care to get right in a web view. Apple's review guidelines reject apps that are no more than a website in a wrapper, so the app has to offer app-like functionality. And once you are in the stores, store policies apply to you, including the billing rules for digital goods.
A sensible sequence for many products: responsive web app first, PWA features where they are cheap, Capacitor when you need the stores, and a native or React Native client only if the interface outgrows the web view.
Decision table
| Your situation | Likely best route |
|---|---|
| B2B tool used at a desk and occasionally on a phone | Responsive web app; PWA features optional |
| Internal or field tool for a known group of staff, mostly Android | PWA. You control installation and can train users |
| Content, booking or ordering product reached mainly through search, links or QR codes | PWA first; store app when repeat use justifies it |
| Consumer product meant for daily use, relying on notifications to bring people back | Store app |
| Revenue from subscriptions or digital purchases made on the phone | Store app, possibly alongside web checkout where rules allow |
| Existing web app, customers asking for “the app” | Capacitor wrapper around the existing front end |
| Bluetooth devices, background location, widgets, health data | Store app, cross-platform or native depending on depth |
| Camera or audio processing in real time, AR, demanding 3D | Native store app |
| Testing demand on a small budget | Web or PWA. Spend the difference on reaching users |
If two rows apply and disagree, let the one about revenue or retention win. A cheaper build that cannot bring users back or take their money is not cheaper.
Cost and time implications
Assume a responsive web app already exists and its mobile layout is good. Using the effort × rate method from our app budgeting guide, where a person-week costs $2,000 at $50 an hour and $6,000 at $150 an hour:
| Route | Added effort | At $50 / hour | At $150 / hour | Release process |
|---|---|---|---|---|
| Add PWA features: manifest, service worker, offline caching, install guidance, web push | 1–3 person-weeks | $2,000–$6,000 | $6,000–$18,000 | Deploy the website |
| Capacitor apps for both stores: native push, store assets, device testing, submission | 3–6 person-weeks | $6,000–$12,000 | $18,000–$36,000 | Store review per release |
| New cross-platform client (React Native) for an app whose client side is about 12 person-weeks | 13–15 person-weeks | $26,000–$30,000 | $78,000–$90,000 | Store review per release |
These are planning estimates. Backend, admin panel and design are shared across all three rows and excluded. If no web app exists yet, the first row becomes the cost of building that web app, and the gap between routes narrows: the expensive part of any product is the product, not its packaging.
Two recurring differences matter more than the build. A PWA has no store maintenance: no yearly target API updates, no policy forms, no review delays. A store app has all of those, and in exchange gets the distribution and billing that a PWA lacks.
A short procedure
- List what the product needs from the device. If anything on the list is in the “cannot do” section, you need a store app.
- Ask how users will find you. Store search and paid installs point to a store app. Links, search engines, QR codes and sales conversations point to the web.
- Ask how you will charge. Digital goods bought on the phone point to store billing. Invoices, web subscriptions and physical services work anywhere.
- Estimate how often people will open it. Weekly or less, a PWA is rarely the bottleneck. Daily, invest in the store app.
- If the answer is “both”, build the web app first in a way that can be wrapped later: responsive layouts, touch-friendly controls, no dependence on browser-only features.
BBR builds web products and store apps from the same skill set, so we have no stake in which you choose. The web application development and mobile app development pages describe how we approach each.