What you will take away
- No store review and one codebase is the real commercial argument.
- Caching strategy per resource type is the whole of service worker design.
- Check platform support for the specific capabilities you need before promising them.
What a PWA is for
A progressive web app is a website that can be installed to the home screen, works offline or on a poor connection, and behaves like an application once opened. No store submission, no review delay, no thirty per cent cut, and one codebase across desktop and mobile.
For content, commerce, booking, internal tools and anything a user reaches occasionally rather than daily, that trade is frequently better than a native app that has to be discovered, downloaded and updated.
The service worker is the whole design
A service worker sits between the app and the network and decides what to serve from cache. Getting that policy right per resource type is essentially the entire engineering problem.
- Application shell and static assets: cache first, updated in the background.
- API data that must be current: network first, with a cached fallback for offline use.
- Images and media: cache with an expiry and a size cap, so storage does not grow without bound.
- Never cache authenticated responses without scoping them to the session - a cached account page shown to the next user is a serious bug.
A service worker with no update strategy is how users end up stuck on a version from three months ago with no way to escape it.
Offline is a data problem, not a caching one
Serving pages offline is straightforward. Letting users change things offline is not: you need local storage of pending writes, a queue that replays when the connection returns, and a rule for what happens when the server has changed the same record in the meantime.
Decide the conflict policy per feature - last write wins, server wins, or ask the user - and show sync state honestly in the interface. Silent data loss is far worse than an explicit "not yet saved" indicator.
Installability and the honest limits
A manifest with icons, a name, a start URL and a display mode makes the app installable, and a well-timed prompt after the user has seen value converts far better than one on first load.
Support for push notifications, background sync and hardware access still varies by platform and version. Check the specific capabilities your product depends on before committing, and design a working experience for the platforms that lack them rather than a broken one.
When a native app is still the answer
If you need reliable background execution, deep hardware access, widgets, or store presence as a distribution channel, build native. If discovery happens through search and the session is occasional, the PWA usually wins on cost and on conversion.
A common sequence works well: launch as a PWA, learn what users actually do, and build native later for the specific capabilities the data shows you need.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
