When a client says "we want an app", the reflexive answer tends to be "native iOS + Android". Two codebases, two app store approvals, two teams of specialists. But for a large share of use cases (internal applications, B2B portals, content platforms) the answer is different: a progressive web app.
After dozens of delivered PWAs, we know where the line is — when a PWA replaces native and when it becomes a limitation. In this article we break down the decision framework and share numbers from real projects.
The best application is the one users actually use. Three clicks to install from the App Store hurt conversion more than a 30% difference in performance.
PWAs enjoy very solid platform support today: service workers (offline), push notifications (Android, and iOS since 16.4), install banners, fullscreen mode, file system access. For 70–80% of business apps, this covers the functionality that would otherwise require separate native projects.
When a PWA is not enough
The boundary lies roughly where you need deep device integration: Bluetooth LE pairing, NFC payments, ARKit/ARCore, real-time video processing, background tasks while the app is closed, or deep OS integration (widgets, share extensions). For these cases native is essential — but that is 15–20% of all projects, not the majority.
- One codebase = half the development budget
- No app store approvals = release cycles measured in hours, not weeks
- Auto-updates — users are always on the latest version with no action required
- Sharing via URL = higher conversion than installing from an app store
- SEO-indexable (unlike native)
- Lighthouse PWA audit = systematic quality control
A PWA is not a cheaper version of native — it is a different architecture with different trade-offs. For B2B portals, e-commerce, content platforms, and internal tools it leads to 50–70% cost savings with comparable or better UX. For projects requiring deep hardware integration, native remains the right choice. Start the decision with concrete feature lists, not gut feeling.