Progressive
web app development

A PWA is not a cheaper native app. It is a different set of trade-offs, and on some projects it is the wrong answer. Here is the honest comparison, so the choice is made before the budget is committed rather than after.

Installation and the home screen
A PWA installs from the browser with no store review and no download. That removes the largest drop-off in the funnel. The trade-off is discovery: nobody browses for your PWA, so every install comes from traffic you already have.

• No store review, no download step
• Install prompt lives in your own traffic
• Poor fit if the store is your acquisition channel

Offline and caching
Service workers let a PWA open and function without a connection. For catalogues, documentation, order forms and field tools this is usually enough. Heavy offline sync with conflict resolution is where the work stops being cheap.

• Reliable for read-heavy offline use
• Forms can queue and submit on reconnect
• Complex two-way sync is not a shortcut

Push notifications
Supported on Android for years. On iOS push works only after the user adds the app to the home screen, and the behaviour differs from native. If notifications are the core of the product rather than a convenience, that constraint should decide the platform.

• Full support on Android
• iOS requires home-screen install first
• Notification-led products belong on native

Hardware and platform access
Camera, geolocation, files and Bluetooth are reachable from a PWA. Background execution, deep OS integration, some sensors and platform-specific APIs are not, or not reliably across browsers.

• Camera, location and files are fine
• Background work is limited
• Check every required API before committing

Distribution and payments
Living outside the store means no store fee and no review queue. It also means no store listing, no ratings, and no in-app purchase rail. For a business tool that is an advantage; for a consumer subscription product it may not be.

• No platform commission
• No listing, no ratings, no store search
• In-app purchase rail is not available

Cost and time to market
One codebase for every platform instead of two, and releases that ship the moment they are ready rather than when a review clears. That is the real saving. It disappears the moment the product needs a native companion anyway.

• One codebase across platforms
• Releases ship without review delay
• Saving is lost if native is needed later

A service worker does not take over the moment a new version ships. It installs in the background, waits for every open tab on the old version to close, and only then activates. Miss that detail and the day goes like this. A team pushes a fix. It checks out in a fresh incognito tab. Users keep reporting the bug. Their tabs never fully closed, so the old worker is still in charge. Forcing an update with `skipWaiting` and `clients.claim()` solves the symptom and buys a new one: scripts can now be swapped out from under a live page. Use that shortcut only with a plan for state that was already loaded.

Cache-first is fast. It is also wrong for anything that changes: a pricing page served from cache can show a number corrected on the server hours ago. Network-first is safe and slow. Every load waits on a round trip, even when the cached copy was fine. Stale-while-revalidate splits the difference. Serve the cached version instantly, fetch a fresh one in the background, swap it in for next time. The real answer is not one strategy for the whole app. Static assets go cache-first. API responses go stale-while-revalidate. Anything transactional goes network-only. Decide route by route.

A manifest with a name, icons and a start URL is necessary. It is not sufficient. Chrome and Edge also want the site visited more than once, over more than five minutes in total, before the install prompt becomes available at all. So a PWA that looks broken because the install button never appears in testing is usually working exactly as designed. The engagement heuristic simply has not been met by a browser that opened the site once and closed it. Testing install behaviour means reproducing that usage pattern. Checking that the manifest validates proves something else.

Reading cached content offline is the easy half. The hard half is what happens when someone submits a form or taps save with no connection at all. The Background Sync API exists for this. The write is queued locally, and the browser retries it once connectivity returns — even if the tab has since been closed. Without that queue there are two outcomes, and both are bad. The submission fails silently. Or it shows a confirmation for something that never left the device. Nothing erodes trust in an app faster.

Web push runs on a subscription model. The browser generates an endpoint and keys through VAPID, the server stores that subscription, and every later push goes to the browser push service rather than straight to the device. Those subscriptions expire. They also get revoked, more often than a native push token does — clearing site data or switching browsers is enough. So a push feature has to detect a failed send and ask for a fresh subscription. Otherwise the list grows while the messages go nowhere.

A service worker sits between the browser and the network for every request it controls. A slow or blocking activation step therefore shows up directly in Largest Contentful Paint and Interaction to Next Paint. The fix is not to drop the service worker. Keep the install and activate handlers minimal. Precache what the first paint needs, not the whole asset list. Push everything non-critical into a background fetch once the page is already interactive.

A PWA built and tested on Chrome for Android meets a materially different feature set on iOS Safari. Push notifications work only after the PWA has been added to the home screen. Background sync is not implemented at all. Storage quotas are tighter, and eviction is more aggressive for an app nobody has opened recently. None of this surfaces until somebody tests on an iPhone. A feature scoped from Android behaviour alone needs a documented iOS fallback before anyone calls it cross-platform.

An installed PWA feels like an app partly because moving between screens does not reload the page. A shell of persistent interface stays mounted while only the content region swaps, the way a native navigation stack works. Wire routing through ordinary anchor tags and full-page requests instead, and every screen change repaints the whole interface. State the user had not saved goes with it. That is the seam that gives away a PWA built as a stack of static pages.

Precached files need a cache name tied to a build version. A fixed string will not do. Otherwise a deploy that changes a stylesheet leaves the old one served from cache indefinitely to everyone who installed the previous version. Cleanup belongs in the activation step: delete any cache whose version does not match the one just installed. Skip it and the PWA keeps every version it has ever shipped inside the user storage quota, until the browser starts evicting things on its own.

A push permission prompt fired the moment someone lands on a PWA has nothing to justify itself against. The visitor has not yet seen a reason to want updates. So the request reads as noise and gets dismissed out of habit. Move the same prompt to the moment right after an action a notification would naturally follow — an order placed, an item saved, a booking finished — and it is judged against something concrete that just happened. The dialog is identical. The context around it is not.

A perfect Lighthouse score confirms that a page meets a set of automated heuristics. It confirms nothing about the install prompt on a mid-range Android phone over a throttled connection. It says nothing about a form with an on-screen keyboard covering half the viewport. Real hardware catches the gap between passing the audit and working for someone holding an actual phone. That is where PWA problems live — in physical constraints a simulator does not reproduce, not in the metrics.

Background Sync is the mechanism that retries a queued offline action once connectivity returns. Chrome and other Chromium browsers on Android support it fully. Safari on iOS does not implement it at all, as of this writing. A PWA built on the assumption that it exists everywhere will lose queued writes on an iPhone, silently, with no error to explain it. The iOS fallback is to retry on the next app open instead of automatically in the background. Design it in from the start. Patching it in after someone notices missing data is the expensive path.

A PWA fits content, commerce and most transactional apps that need reach across platforms without a store review cycle. It fits badly where a feature depends on deep OS integration the browser sandbox does not expose. Full Bluetooth access. Background location tracking. Several camera and sensor APIs that stay native-only. Scoping honestly means checking the specific platform APIs a feature needs before committing to the format. Discovering a native-only requirement mid-build costs the build.

An analytics call fired the ordinary way is a fetch straight to a tracking endpoint. Send it while the device is offline and it fails and disappears. The gap lands in exactly the sessions where offline behaviour matters most. The fix is to queue analytics events through the same offline storage used for other writes, then flush them when connectivity returns. That is what keeps an offline session from becoming an invisible one in the reporting.

A native app waits for the user to approve a store update. A PWA does not: the new version is on the server the moment it is deployed. The only question is when the installed copy notices. Left unhandled, that gap stretches. Someone can run a stale version for weeks because they never fully closed the tab that would trigger the service worker to check. A small in-app banner closes it — a new version is available, refresh to update — without forcing a disruptive reload the second a deploy lands.

One square icon can look fine on Android and come out cropped into an odd shape on a different launcher. Android applies its own mask over whatever is supplied, unless the icon is built to the maskable-icon spec with safe padding around the visible logo. iOS has separate requirements again, for touch icons and splash screens, and shares no format with Android. Supply one icon and hope it scales, and the logo ends up half-cropped on the one home screen the user actually looks at.

A push handed to the browser push service does not necessarily reach the device instantly. It may not arrive at all. The service can rate-limit a sender pushing too many messages too quickly, and a device that is offline or deeply asleep queues the message rather than delivering it. Treating sent and delivered as the same event overstates reach. Track delivery and open separately, where the platform reports them. That is what shows whether a campaign reached anyone or merely left the server.

Browsers grant an installed PWA a storage quota. The grant is not permanent. Under storage pressure a browser can evict an entire origin cache, starting with sites nobody has opened recently. So an app that assumes offline data will always be there needs a plan for the day it is not: detect that the cache came back empty and re-fetch, rather than crashing on a value it expected to find locally.

A PWA rendered entirely client-side can leave a crawler looking at an empty shell. The install prompt works. Offline support works. The page that was supposed to rank had no readable content at crawl time, because it loaded in after the initial HTML response. Server-side rendering or pre-rendering that first response fixes the visibility problem. None of the app-shell behaviour is lost once the page has loaded and the service worker takes over navigation.

Browsers implement PWA capabilities at different speeds. Assuming a feature exists because the spec describes it is how an app breaks silently on a browser that has not shipped it. Check for the feature before using it. Fall back to simpler behaviour when it is missing. That is what keeps a PWA usable across the full range of browsers it will actually be opened in, rather than the single one it was built and tested against.

A service worker caching an API response will keep serving it after the auth token behind it has expired. The user sees stale data instead of a clean prompt to log in again. The cache has no awareness that the credential it was fetched with has stopped being valid. Two ways out. Exclude authenticated responses from long-lived caching. Or check token validity before serving anything cached. Either beats assuming a cached response is always safe to reuse.

Wrapping a PWA in a native shell, through something like Capacitor, buys a handful of APIs the browser sandbox does not expose: deeper Bluetooth access, certain background location modes, native share sheets richer than the Web Share API. It also buys a native build pipeline, store listings and platform review cycles for what used to be a pure web deployment. Make that trade when a specific native capability is a hard requirement. Avoid it when the gap is something the web platform already covers.

A minimal service worker copied from a tutorial passes a demo. Install, cache a few assets, answer offline with a fallback page. Production traffic asks for more. Cache versioning. Error handling for a failed fetch. A strategy for partial cache failures. All of it has to exist before real users depend on it. The distance between it installs and it is production-ready is exactly the part nobody sees while checking that the install prompt appears.

A cache bug usually shows up only on a device that installed an earlier version and has carried stale service worker state ever since. A fresh install on a clean profile will not reproduce it. That makes works on my machine a weaker signal for a PWA than for most web apps. Reproducing a report reliably starts with the reporter cache and service worker version, not with code that is identical for everyone.

A checkout or booking flow that loses connectivity mid-submission needs a defined behaviour for that exact moment, and a generic offline page is not it. Did the request reach the server before the connection dropped? Is a retry safe, or does it risk a duplicate charge? Does the user need an honest we are not sure, please check state instead of a false success or a false failure? Designing for that ambiguous middle is what separates a PWA that handles flaky connectivity from one with an offline mode bolted onto the happy path.

The same PWA renders differently depending on how it is running. Standalone, installed to a home screen, or open in an ordinary browser tab. Safe areas around a notch appear or do not. Browser chrome is present or gone. Viewport height is calculated differently once the address bar disappears. Test only in a regular tab and the layout issues specific to standalone display mode never surface — which is the mode most people experience once they have installed the app.

A site with existing rankings and inbound links can lose both during a PWA migration. URLs change. The pre-rendered content the crawler used to see becomes a client-rendered shell. Redirects from the old structure to the new one come out incomplete. Treating the migration as a technical SEO project as much as a development one is what prevents that. Map every existing URL to its new equivalent before launch, not after the traffic drops.