FSD Frontend System Design

Part IV — The Reach · Lesson 9.2

Progressive Web Applications (PWAs)

In one lineA website that installs, launches from the home screen, works offline, and receives push.

Where you've seen itTwitter Lite. Installable, offline-capable, and orders of magnitude smaller than the native app.

  • Time15 min
  • DiagramPWA capability checklist + install flow
  • Chapter9 · Offline Support

Diagram

diagram
THE THREE REQUIREMENTS — all mandatory

  ┌──────────────────────────────────────────────────────────┐
  │ 1. HTTPS              service workers refuse to run      │
  │                       anywhere else (3.6)                │
  │ 2. manifest.json      name, icons, start_url, display    │
  │ 3. service worker     with a fetch handler (9.1)         │
  └──────────────────────────────────────────────────────────┘
              │
              ▼
   browser offers install ──► home screen icon ──► launches
                                                   standalone,
                                                   no browser UI
diagram
MANIFEST — the fields that actually matter

  {
    "name": "Notes",                    full name, install prompt
    "short_name": "Notes",              home screen label (~12 chars)
    "start_url": "/?source=pwa",        ← tag it to measure installs
    "display": "standalone",            no address bar
    "background_color": "#0d0f14",      splash screen
    "theme_color": "#3b4ee0",           OS chrome tint
    "icons": [192px, 512px, maskable]   ← maskable or Android crops it
  }
diagram
CAPABILITY LADDER — progressive means it degrades cleanly

  works everywhere      ┌────────────────────────────┐
                        │ responsive HTML + HTTPS    │
                        ├────────────────────────────┤
  most browsers         │ offline shell (SW cache)   │
                        ├────────────────────────────┤
                        │ installable (manifest)     │
                        ├────────────────────────────┤
  varies by platform    │ push notifications         │
                        │ background sync            │
                        │ file/share/contacts APIs   │
                        └────────────────────────────┘

  Every layer is optional. Feature-detect; never assume.

How it works

  1. Serve over HTTPS, add manifest.json, and register a service worker with a fetch handler — that's the installability bar.
  2. Handle the install prompt yourself: capture beforeinstallprompt, show your own button at a sensible moment, then call prompt().
  3. Provide maskable icons at 192px and 512px, or Android will crop your logo into a circle badly.
  4. Design the offline state as a real state — a proper "You're offline, here's what's cached" screen, not a browser error.
  5. Ask for push permission in context, after the user does something that implies they want it. A prompt on first load gets denied permanently.

Trade-offs

PWANative app
No store review, instant updatesStore discovery and trust
One codebase, linkable, indexableFull device API access
Tiny install sizeBetter background execution
iOS support is partialConsistent platform behaviour

Be honest about iOS: installability and offline work, but push support arrived late and only for installed apps, and storage is evicted more aggressively. Design so that the PWA-only features are enhancements, never the core flow.

Interview angle

"When would you build a PWA instead of a native app?"

  • When reach and update speed matter more than deep device integration — content, commerce, tools, internal apps.
  • When install friction is the main funnel problem: a link that becomes an app beats a store listing.
  • Not when you need background location, tight OS integration, or store-based discovery and billing.

Recap

  • HTTPS + manifest + service worker is the whole installability bar.
  • Every capability above the shell is progressive — feature-detect and degrade.
  • Ask for push in context; a first-load prompt is a permanent denial.