PWA Installable Web
Use this stack when the product is web-first, can ship through normal HTTPS delivery, and needs installability, offline behavior, local storage, notifications, or light OS integration without going fully native.
PWA is not a framework. It is a browser platform stack: a web app manifest for app identity, service workers for network and background events, Cache Storage for URL resources, IndexedDB for structured local data, and browser-specific install surfaces.
Choose PWA When
| Signal | Why PWA fits |
|---|---|
| The app is content, workflow, admin, reporting, forms, dashboards, or light productivity | The web ships fastest and reaches desktop/mobile without store-first release work |
| Offline is useful but not safety-critical | You can cache the app shell, keep local IndexedDB data, and sync when online |
| Browser APIs cover the device needs | File handling, share targets, notifications, clipboard, media, and hardware APIs may be enough with feature detection |
| Store presence is optional or secondary | Browser install, Microsoft Store, and Android TWA are possible without rewriting the app |
| One solo developer must maintain it | One deployable web app usually beats separate native codebases |
Avoid PWA When
| Signal | Better default |
|---|---|
| Deep background execution is core | Native Android/iOS or desktop |
| You need restricted or OS-specific APIs | Native stack for that platform |
| Push/notifications must be predictable across every target | Native or server-driven channels with fallback |
| Store policy, subscriptions, or in-app purchase rules are central | Native or store-specific wrapper planning first |
| The UI needs high-performance native rendering | Native, Flutter, or a desktop stack |
Gotcha: Installability does not equal offline readiness. A browser may allow an app to be installed even when the offline story is weak. Treat install, offline data, sync, update, and recovery as separate gates.
Stack Shape
| Layer | Default | Notes |
|---|---|---|
| Delivery | HTTPS static or app server | Localhost works for development; production needs a secure context |
| Identity | Web app manifest | Stable id, start_url, scope, display mode, icons, screenshots, theme, shortcuts |
| Runtime | Service worker | Request interception, app-shell caching, offline fallback, push, sync events, update control |
| Resource cache | Cache Storage | URL-addressable HTML, JS, CSS, images, fonts, API responses |
| App data | IndexedDB | Structured user data, blobs, queues, sync metadata, exports |
| Packaging | Browser install first | Add Microsoft Store package, Android TWA, or PWABuilder only when distribution needs it |
| Testing | DevTools, Playwright, device smoke | Lighthouse PWA audits are not enough and are de-emphasized |
First Pages To Read
- Decision Guide
- Starter Shape
- Quality Gates
- Runtime Model
- Installability
- Web App Manifest
- Service Workers
- Offline Storage
- Background Work
- Package For Stores
- Test And Debug
- When Not To Choose PWA
Minimum Done Criteria
Do not call a PWA shippable until these pass:
| Area | Proof |
|---|---|
| Install | Manifest is valid, icons render, app can be installed on the target browser/device |
| Offline shell | First loaded app can reload to a useful offline state |
| Data | IndexedDB schema, quota behavior, export/backup, and eviction risks are handled |
| Updates | Service worker update UX avoids stale assets and reload loops |
| Push | Permission, subscription, send, display, click, unsubscribe, and denial paths are tested |
| Background work | Unsupported browser path has a foreground retry fallback |
| Stores | Wrapper policy, signing, identity, scope, and manifest package metadata are verified |
| Tests | Playwright covers offline/service worker regressions; real device/browser install is checked |