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

BoundaryPractical meaning
OriginStorage, service worker scope, permissions, and caches are origin-bound
ScopeA service worker controls pages under its registration scope
Secure contextProduction PWA capabilities require HTTPS
Browser engineInstalled PWAs still inherit browser support and limitations
OS surfaceLaunch 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.