Client Platforms · 6 of 6

PWA — Progressive Web App

A web app that installs to the home screen, runs offline, sends push notifications, and feels like a native app — without an app store. The middle path between web and native.

Service WorkerWeb App ManifestOfflinePushInstallable
← Back to Client Side
Quick Facts

At a Glance

Basic Concepts

  • PWA = a regular website that adds a few APIs to become installable, offline-capable, and push-enabled.
  • Three core ingredients: HTTPS, a Web App Manifest, and a Service Worker.
  • Installs to home screen / desktop with no store review and no developer-account fee.
  • Updates ship instantly — no app review queue, no version skew.
  • Same codebase as your website. The PWA is the website, with a few extra files.
Mechanics

The Three Ingredients

1. HTTPS

Required. Service workers, push notifications, geolocation, camera, and most modern APIs are gated on a secure context (localhost exempted for dev).

2. Web App Manifest

A small JSON file linked from your HTML that tells the OS how to install the app: name, icons, theme color, start URL, display mode (standalone hides the browser chrome), screenshots for the install card.

{
  "name": "My App",
  "short_name": "My App",
  "start_url": "/",
  "display": "standalone",
  "theme_color": "#1a4d8c",
  "background_color": "#ffffff",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}
3. Service Worker

A script that runs in a separate worker thread, intercepts network requests, and can serve from cache when offline. Acts as a programmable proxy between the page and the network.

  • Lifecycle: install (cache app shell) → activate (clean old caches) → fetch (intercept requests).
  • Updates in the background; activates on next page reload.
  • Can receive push messages and show notifications even when the page is closed.
  • Cannot touch the DOM directly — it talks to pages via postMessage.
Patterns

Caching Strategies

StrategyWhat it doesUse for
Cache FirstServe from cache, fall back to networkStatic assets, fonts, app shell
Network FirstTry network, fall back to cacheAPI responses where freshness matters
Stale While RevalidateServe cache immediately, refresh in backgroundFeeds, dashboards — fast and eventually fresh
Network OnlyAlways go to networkPOSTs, analytics, anything mutating
Cache OnlyNever hit networkPre-cached offline content

Workbox (Google) is the de-facto library for writing service workers — handles routing, strategies, precaching, and updates.

Capabilities

What PWAs Can Do (Today)

  • Install to home screen / desktop with a launcher icon.
  • Run offline via service worker caches.
  • Push notifications (iOS Safari finally added this in 2023, gated on home-screen install).
  • Background sync — queue mutations while offline, replay when back online (Chromium only).
  • Camera, microphone, geolocation, accelerometer, Bluetooth, USB, NFC — all available via Web APIs (Bluetooth/USB/NFC mostly Chromium).
  • File system access via the File System Access API (Chromium) or download/upload elsewhere.
  • Share integration via the Web Share API.
  • App shortcuts from long-pressing the icon.
Limits

What PWAs Still Can't Do

  • App-store discovery — Microsoft Store accepts PWAs; Apple App Store and Google Play don't (you'd wrap with TWA / PWA Builder / Capacitor).
  • Persistent background tasks are limited everywhere; iOS especially restrictive.
  • Deep iOS integration — Live Activities, widgets, App Intents, HealthKit, ARKit are off-limits.
  • In-app purchases through stores aren't available — but you also avoid the 30% cut on web payments.
  • Storage quotas can be evicted by the OS under pressure (especially on iOS) — don't treat IndexedDB as durable.
  • Safari lags — push permission flow, install UX, and some APIs land later or not at all.
Bridges

Wrapping a PWA for the Stores

WrapperTargetHow
TWA — Trusted Web ActivityGoogle PlayAndroid shell that opens your PWA fullscreen via Chrome Custom Tabs.
PWA BuilderPlay, Microsoft Store, App StoreMicrosoft tool that generates wrapper projects from a manifest URL.
CapacitoriOS, Android, WebNative shell with JS bridge; full access to native APIs from the same web codebase.
Picking

When PWA Is the Right Choice

Existing web app, mobile-shaped

Add a manifest + service worker. Big ROI for low effort.

Avoiding store fees / review

Web + PWA gets you a 0% cut and instant updates.

Internal tools / line-of-business

PWAs are perfect — no MDM-store friction, deploy via URL.

Need deep native integration

Pick native or Capacitor — PWA alone won't reach widgets / HealthKit / Live Activities.

Pitfalls

Common Anti-Patterns

  • Cache lock-in — service worker caches a broken build forever. Always version caches and clean up on activate.
  • Hijacking refresh — buggy fetch handlers can serve stale HTML and break updates.
  • No update prompt — user gets old code until they remember to refresh; show a "new version available" toast.
  • Missing icons / wrong manifest — install banners silently don't appear; test with Lighthouse.
  • Treating IndexedDB as durable — iOS evicts after 7 days of disuse for non-installed sites.
  • Push on iOS without install — permission UX requires home-screen install first; a generic "Allow notifications" prompt won't work.
Continue

Other Client Platforms