Hire PWA Developers

A progressive web app earns its place when you want one deployable thing, instant updates and no store review, and the app can live within what the browser allows — internal tools, field forms, booking and ordering flows, anything a user reaches from a link rather than an app icon they searched for. It is the wrong answer when you need deep hardware access or reliable push on iOS.

A web app manifest makes a site installable. A service worker makes it an application. Auditing our own estate, several products had the first and none had the second — an icon, a name, a theme colour, a standalone display mode and shortcuts, all correct, and no offline capability whatsoever because nothing was intercepting requests. That is the normal state of things, and it is worth saying plainly: most sites described as progressive web apps are installable web pages.

Cache strategy is chosen per route, never globally

There is no single correct caching policy, which is why a blanket one is always wrong somewhere. The application shell and hashed static assets can be cached first and served instantly, because their filenames change when their contents do. An API response that drives a decision should go to the network first and fall back to cache with a visible indication that the data is old. Reference data that changes weekly can be served from cache while it revalidates in the background.

The judgement is not in knowing those three patterns. It is in deciding, for each route, what a stale answer costs the person reading it — and in showing them when they are looking at one.

The update problem, which is the one that actually bites

This is the failure mode unique to the technology and the reason it deserves care. A service worker that is already installed on a device controls that device. A new one downloads, then waits until every tab under the old one has closed — and on a tool people leave open all day, that is never.

The consequences are not theoretical. Ship a worker that caches the application shell too aggressively and users can be pinned to an old build indefinitely, including the build with the bug you have just fixed. Any serious deployment therefore needs three things decided before launch: how a waiting worker is activated, how the user is told an update is ready, and a way to unregister everything remotely if a worker ever has to be recalled.

Design the removal path before the caching strategy. It is the only part of this that you cannot fix by shipping again.

What iOS actually supports, stated without optimism

Push notifications work, but only after the user has added the app to their Home Screen — there is no notification from a page they merely visited, and the install action is buried in a share menu rather than offered by a prompt. Background sync, which is the mechanism that would flush a queue after the tab is closed, is not available in Safari at all. Storage can be evicted.

None of that makes a PWA the wrong choice; it makes certain promises the wrong promises. If your design depends on data leaving the device while nobody is looking at the app, it will not work for half your users, and the correct response is a design where the user can see what has not yet been sent.

Where a PWA is the wrong choice

Anything requiring deep hardware access — Bluetooth peripherals across all browsers, background location, integrated scanner hardware, MDM enrolment on a managed fleet. Anything where push has to be reliable on iOS without an install step. Anything where the business needs to be found in an app store, because a link is not a distribution channel for a consumer product.

And anything where the offline data model is genuinely complex. Browser storage is capable, but an app with a substantial local database and real conflict resolution is easier to build and much easier to debug natively.

What we interview for

Listen for honesty about platform limits. A candidate should be able to state exactly what iOS supports today, what background sync does and does not guarantee, and how they handle a user whose storage is evicted. Ask how they ship an update to a device already running an old service worker. Anyone who describes a PWA as equivalent to a native app has not maintained one.

Then the diagnostic: a user reports that the site shows old data and a hard refresh does not fix it. What are the three places that could be caching, and in what order do you check them. Engineers who have run one of these answer with the worker, then the cache storage, then the HTTP layer. The rest suggest clearing the browser.