Engineering · 5 min read
PWA or native app: when a web app is the right call
Published 21 July 2026 · Updated 5 September 2026 · By Sam Fourie, Niddo
Most business products should ship as a progressive web app first: one codebase, installable on phones and desktops, tolerant of bad connections, no app-store gatekeeping, and updated the moment you deploy. Go native when you truly need deep hardware access, background processing, or a consumer app whose distribution lives in the stores.
What a PWA is
A progressive web app is a web application built so that phones and desktops treat it like an installed app: an icon on the home screen, its own window without browser chrome, push notifications, and enough caching to open and keep working when the connection drops. It is delivered by a link, not a store, and it updates when you deploy.
What you get
- One codebase for desktop, iPhone and Android, which is the biggest cost lever there is.
- Install to home screen and a full-screen experience on both mobile platforms.
- Push notifications on Android and, since iOS 16.4, on iPhone when the app is installed.
- Offline tolerance: the shell and recent data cached, so a guide in a basement or a workshop with bad signal still sees the day.
- Instant updates, no store review, no version fragmentation.
- Search engines can index the public parts, and a link is all it takes to onboard someone.
What you give up
- Some hardware and system access: background location, Bluetooth on iOS, certain sensors and background tasks.
- App-store presence, which matters for consumer discovery and almost never for business software.
- A few iOS limitations around notifications and storage that a native app does not have.
A decision table
| If you need | Choose |
|---|---|
| Staff or customers using it on phones and desktops | PWA |
| Fast iteration and instant updates | PWA |
| Offline tolerance for forms and recent data | PWA |
| Push notifications for business users | PWA (installed) |
| Background GPS tracking, Bluetooth peripherals, heavy camera or sensor work | Native |
| A consumer app whose growth depends on store discovery | Native, or both |
| Deep integration with the OS (widgets, wallets, background sync) | Native |
The cost difference
Native means either two codebases or a cross-platform framework plus store operations for two platforms, on top of the backend both need anyway. In practice that doubles the interface budget and adds an ongoing release cost. A PWA puts that money into the workflow instead. See what a SaaS costs.
Three of ours are PWAs
One Journey's guides claim tours and run their day from an installed PWA on their phones. PanelDesk runs on the shop floor and in the office from the same app. ARC Legacy ships as a responsive web app and PWA by design. In each case a native app would have doubled the cost and delivered nothing the users needed.
When we would still build native
When the product is the phone: background tracking, hardware peripherals, or a consumer app where store presence is the growth channel. Then we build native on the same backend and API, usually with React Native, so the investment in the platform is not repeated.
Questions
People also ask.
Can a PWA send push notifications on iPhone?
Yes, since iOS 16.4, when the app has been added to the home screen and the user has allowed notifications.
Can a PWA work offline?
It can open, show cached screens and recent data, and queue actions to sync when the connection returns. It is not a substitute for a fully offline-first native app if that is the core requirement.
Can we move from a PWA to native later?
Yes. The backend, data and API are shared, so a native app is an additional interface rather than a rewrite.
Will users find it without an app store?
Distribution is your job either way. For business software a link in an email or a QR code on the wall beats a store search, and onboarding is one tap.