PWA Runtime Model
A PWA is still a website. Installation adds operating-system launch surfaces, but the runtime is the browser engine plus origin-scoped storage and service worker control.
flowchart LR
user[User] --> installed[Installed app window]
user --> browser[Browser tab]
subgraph client["Client device"]
direction TB
installed --> app[Web app]
browser --> app
app --> manifest[Manifest]
app --> sw[Service worker]
sw --> cache[(Cache Storage)]
app --> idb[(IndexedDB)]
sw --> idb
end
subgraph origin["Web origin"]
direction TB
server[App server or static host]
api[API server]
end
subgraph platform["Platform services"]
direction TB
push[Push service]
os[OS integration]
end
sw --> server
app --> api
push --> sw
manifest --> os
What to notice:
- The manifest describes app identity and install presentation. It does not execute code.
- The service worker sits between controlled pages and network requests. It can also receive push and sync events.
- Cache Storage stores request/response resources. IndexedDB stores app data.
- Installed windows and browser tabs are both web clients. Scope and origin still matter.
Runtime Boundaries
| Boundary | Practical meaning |
|---|---|
| Origin | Storage, service worker scope, permissions, and caches are origin-bound |
| Scope | A service worker controls pages under its registration scope |
| Secure context | Production PWA capabilities require HTTPS |
| Browser engine | Installed PWAs still inherit browser support and limitations |
| OS surface | Launch icon, app switcher, file handling, share targets, and notifications are platform-specific |
Gotcha: Do not keep critical state in service worker globals. Browsers can terminate and restart service workers. Persist state in IndexedDB or send it to the server.