Progressive web apps: app feel without the app store
A PWA is a website that behaves like an app: installable on the home screen, fast, and offline-capable to some extent. It's the smartest choice when you want to reach both iOS and Android with one codebase, skip the app stores' review and fees, and when your audience has low willingness to download an app from a store.
A progressive web app, or PWA, is a website that has borrowed an app’s best qualities: it can be added to the home screen, opened in its own window without the browser’s address bar, load fast, and work partially offline. The point is to skip both the app stores and the cost of building separately for iOS and Android. But the technology has real limitations, and they differ between platforms. Here’s an honest look at what a PWA can do in 2026, when it’s the right choice, and how it stacks up economically.
What a PWA can and can’t do on iOS versus Android
On Android, a PWA comes close to a full-fledged app. It installs from the browser, can send push notifications, work offline against cached content, and be packaged for Google Play if needed. For the vast majority of use cases, Android users barely notice it isn’t a “real” app.
On iOS, the picture is more mixed. A PWA works, but Apple has historically given web apps less room than native apps. Push notifications require the user to have added the app to the home screen and have been more limited, offline mode is tighter, and some hardware-close features simply aren’t available. That doesn’t mean a PWA is wrong for iOS – just that you should test the features you depend on before committing.
Common to both is that deep device integration – advanced camera control, Bluetooth with accessories, background execution – is where a PWA hits its limit. If the product needs that, a native app is the right tool.
The reason for the difference is simple: a PWA lives inside the browser and only gets access to what the browser lets through. On Android and in Apple’s browser engine, that door opens to different widths, and Apple has, for several reasons, chosen to keep it a bit more closed. For you as the client, that means one thing in practice – test the features you depend on, on a real iPhone, early, instead of assuming that what works on Android also works on iOS.
Use cases where a PWA is the right choice
A PWA shines in situations where the app store is an obstacle rather than a help.
- Internal staff and field work. If the tool will only be used by your own employees, there’s no reason to go through the stores’ review process. A PWA is distributed via a link and updates instantly.
- B2B portals. Customer portals, order tools, and dashboards that already live on the web get an app feel without you having to build and maintain two separate apps.
- Low willingness to download. When your audience isn’t keen to install apps – occasional visitors, campaigns, services used rarely – a PWA dramatically lowers the barrier. The user is up and running directly in the browser and can add the app if it becomes a habit.
The common thread: reach and simplicity weigh more than store presence and deep device integration.
Cost compared to store apps
The economic logic is the PWA’s strongest argument. With a store strategy, you effectively build and maintain three things: a website, an iOS app, and an Android app – or a shared codebase that still needs platform-specific adjustments – plus store accounts and ongoing reviews. With a PWA, it’s one codebase that reaches everyone.
| Item | PWA |
|---|---|
| Codebases to maintain | One – the same as the website |
| App store fees | None (you skip Apple's 99 USD/year and Google's one-time 25 USD) |
| Updates | Instant, no review wait |
| Distribution | Link – no download from a store |
The savings are clearest in maintenance: an update rolls out on the web and reaches everyone at once, without waiting for store review. At the same time, be honest in the calculation – if the PWA requires a lot of extra work to mimic native features, the advantage shrinks, and then a native app can be worth the money. So look at the whole lifecycle, not just what the first version costs.
Common mistakes to avoid
The first mistake is choosing a PWA to save on cost and then still demanding it behave exactly like a native app on every point. That builds expensive workarounds that eat up the savings – and the result ends up neither a truly good website nor a truly good app. Decide early which native features you actually need, and accept that a PWA compromises on the rest.
The second is forgetting discoverability. A PWA doesn’t show up in the stores, so someone has to guide the user to add the app to the home screen. Without a clear prompt in the interface, the install rate stays low, and then you lose the whole point of the app feel. Plan for how you’ll ask the user to install – it doesn’t happen on its own.
How to decide
Ask three questions: does the product need deep device integration or a store presence? Are push and offline on iOS business-critical? And what matters most to your audience – a low barrier, or the feel of a store app? If the answers land on reach, simplicity, and cost control, a PWA is often the smartest choice. Want help deciding? Our services look at your specific requirements, and you can always get in touch with a short description of the idea.
Frequently asked questions
Can a PWA send push notifications on iPhone?
Yes, but with caveats. Push in a PWA only works on iOS once the user has added the app to the home screen, and support has historically been more limited than on Android. If notifications are business-critical for iOS users, test carefully, or consider a native app for that specific piece.
Does a PWA show up in the App Store and Google Play?
Not automatically. A PWA is installed from the browser, not from the stores, which is both a strength and a weakness. You skip the review process and fees, but lose the discoverability and trust that a store presence provides. On Android, you can package a PWA for Play; on iOS, the path is trickier.
Does a PWA work offline?
Partly. A PWA can cache content and shell so the app opens and shows earlier data without a connection, but it's rarely as fully offline-capable as a native app. For simpler offline needs, the technology is more than enough; for heavy offline functionality, a native app is often better.
Is a PWA always cheaper than a native app?
Usually, since you build and maintain one codebase instead of a website plus two apps. The savings are greatest in maintenance over time. But if the PWA requires a lot of extra work to mimic native features, the difference can shrink – calculate the whole lifecycle, not just the build.
Can we start with a PWA and build a native app later?
Yes, it's a common and reasonable path. A PWA lets you launch fast and cheap, validate the need, and gather users. If it turns out you need deep device integration or a store presence, you can build a native app on those learnings – often with the same backend.