Progressive Web App Development

Installability starts with a manifest that names the app, sets the start URL and declares icons at the sizes a phone expects. The display mode removes browser chrome, and the scope decides which links stay inside the installed experience. Without those details the browser offers a bookmark, not an install.

Android and desktop browsers show an install prompt when their criteria are met; iPhone users add the app from the share sheet. We design a first-run hint for each case rather than assuming everyone sees the same button. After installation the icon, splash screen and theme colour should match the brand, because the first impression is now outside the website.

Caching a page is easy; keeping data correct across a lost connection is the hard part. We precache the application shell, apply a network-first or stale-while-revalidate strategy per route, and version every cache so an old shell cannot pair with a new API.

Writes made offline go into a queue with a client-generated identifier. When the connection returns, the queue replays in order, and the server rejects duplicates by that identifier. Conflicting edits need a stated rule, usually last-write-wins with a visible history, because a silent merge is worse than a prompt. Storage eviction is also real: the browser can clear cached data under pressure, so nothing critical lives only in the cache.

Push on the web runs through a service worker and a push subscription. The permission prompt should appear after a user action that explains the benefit, never on first load. A denied prompt is difficult to recover, so timing is part of the feature.

iPhone support exists but requires the app to be installed to the home screen, and the behaviour differs from Android. Desktop browsers have their own notification settings. We test delivery, deep links and quiet hours on each target, and provide an in-app inbox so a missed notification is not a lost message.

A PWA wins when the product is mostly screens, data and workflows: a catalogue, a booking flow, a customer portal, an internal dashboard, a field form. One codebase, one release path and one testing effort replace two platform teams. Updates reach every user on the next load instead of waiting for store review.

Search visibility is another advantage. A PWA can be indexed, linked and shared like a website, while an app store listing has to earn discovery separately. For a business whose acquisition depends on search, that is a material saving rather than a technical nicety.

Heavy hardware is the clearest boundary. Bluetooth device control, NFC payments, continuous background location, advanced camera pipelines and AR are unreliable or unavailable in a browser. If the product's value depends on one of those, a native build is the honest choice.

App-store-only audiences are the second. Some enterprises distribute through a managed store, and some consumers simply trust a listing they can find. Offline durability and background sync are the third: a PWA can queue work, but the operating system may suspend it in ways a native service does not.

The floor covers a defined screen set, an installable shell and a basic API connection. Offline editing, push, payments, multi-role dashboards, integrations and a design system each add work. Offline synchronisation is usually the largest single line because it is a small distributed system inside the app.

Performance is another. A PWA is judged on first load, so image handling, caching strategy and bundle size belong in the build. Treating them as a later optimisation is what produces an installable app that users abandon before the first screen.

We install the build on an entry-level Android phone, an iPhone and a desktop browser, then test the same journey on each. The checks cover a cold start, an offline edit, a reconnection, a push deep link and an update while a screen is open. Analytics and error reporting are verified before launch, not after a complaint.

The release then goes to a small group through a preview URL, with the manifest and service worker served from the production domain. A PWA that installs from staging but not production is usually a scope, HTTPS or caching-header mistake, and it is cheaper to catch before announcement.