PWA

Information

Progressive Web Apps (PWAs) are web applications that use standard browser capabilities to provide an app-like experience. A PWA is still a website, but it can support installation, offline work, background updates, push notifications, and a more resilient user experience on unreliable networks.

If the goal is to make a PWA feel as installable as possible on handheld devices, the design should prioritize mobile browser compatibility, home-screen installation flows, standalone display, touch-friendly navigation, and predictable behavior on Android and iOS-like environments. A PWA cannot become a fully native application on every device, but it can be designed to maximize the chance that users see an install prompt or can add it to the home screen and use it as an app-like entry point.

For practical work, it is useful to think about a PWA as a combination of:

Architecture and Structure

Typical PWA structure includes the following parts:

In practice, a PWA should be organized so that the user interface can start without waiting for all backend requests. Critical rendering assets should be separated from dynamic data. Static resources should be versioned so they can be cached safely and updated predictably.

Environment Restrictions

PWAs run inside the browser environment and therefore inherit browser security and platform restrictions.

General Restrictions

Development Environment Restrictions

Development usually differs from production in important ways:

When developing a PWA, it is important to test both first-load online behavior and repeated loads with network throttling, offline mode, and stale caches.

Requirements

At minimum, a production-quality PWA should define and verify the following requirements.

HTML Requirements

The main HTML page should include at least:

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="theme-color" content="#ffffff">
    <meta name="description" content="Application description">
    <link rel="manifest" href="/manifest.webmanifest">
    <link rel="icon" href="/icons/icon-192.png">
    <title>Application name</title>
</head>
<body>
<div id="app"></div>
<script src="/app.js"></script>
</body>
</html>

Common expectations:

Manifest Requirements

The web app manifest should normally contain:

For handheld-device installability, it is also strongly recommended to define:

Example:

{
    "id": "/",
    "name": "Application name",
    "short_name": "App",
    "start_url": "/?source=pwa",
    "scope": "/",
    "display": "standalone",
    "background_color": "#ffffff",
    "theme_color": "#ffffff",
    "description": "Application description",
    "icons": [
        {
            "src": "/icons/icon-192.png",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "/icons/icon-512.png",
            "sizes": "512x512",
            "type": "image/png"
        },
        {
            "src": "/icons/maskable-512.png",
            "sizes": "512x512",
            "type": "image/png",
            "purpose": "maskable"
        }
    ]
}

Installability Requirements

To maximize installability on many handheld devices, the application should satisfy all of the following:

Installability is vendor-specific. Some browsers show an install prompt automatically, some require a manual browser menu action such as “Add to Home Screen”, and some handheld environments support only a subset of manifest or service worker features.

Service Worker Requirements

The service worker should:

Operational Requirements

Offline Work

Offline support should be designed intentionally, not treated as a side effect of caching.

Useful offline patterns include:

Not all data should be cached. Sensitive, short-lived, or large datasets should be evaluated carefully before local persistence is enabled.

Handheld Device Notes

Installability and app-like behavior differ across handheld platforms.

Android and Chromium-based Browsers

Usually provide the best PWA installability support:

iPhone and iPad Safari

Support is more limited and should be planned for explicitly:

For broad handheld support, documentation and UX should never assume one identical install flow everywhere. Users may need platform-specific instructions even when the application itself remains the same.

Offline Storage Options

Several browser storage mechanisms can be used depending on the data type and lifecycle.

Cache Storage

Good for:

Usually accessed from the service worker. Best suited for deterministic asset and response caching.

IndexedDB

Good for:

IndexedDB is the usual choice for serious offline-capable applications.

localStorage and sessionStorage

Good only for small and simple values such as:

These APIs are synchronous and should not be used for large or critical offline data.

Tools and Libraries for Offline Storage

The browser APIs above can be used directly, but in practice many projects use helper libraries to make offline storage, cache management, and synchronization easier to maintain.

Workbox

Useful for:

Workbox is one of the most common choices when the application needs a structured way to manage service worker caching without writing all cache logic manually.

Dexie

Useful for:

Dexie is a practical wrapper around IndexedDB and is often easier to work with than the raw browser API.

localForage

Useful for:

localForage is a good option when the project wants something more capable than localStorage but simpler than using raw IndexedDB directly.

idb

Useful for:

idb is suitable when the team wants to stay close to the platform API while avoiding the verbosity of native IndexedDB.

PouchDB

Useful for:

PouchDB can be useful for some offline-first designs, although it fits best when the application architecture is built around document replication patterns.

Choosing a Library

Typical selection guidance:

Even when a helper library is used, storage quotas, eviction behavior, browser compatibility, and security rules still come from the browser platform.

Working with Backend

The backend remains the authoritative data source in most PWA architectures. The frontend should be designed to tolerate temporary disconnection without corrupting user actions.

Useful backend integration practices:

For write operations performed offline, define a synchronization strategy explicitly:

When the installed PWA is expected to behave like a handheld app, backend APIs should also minimize cold-start cost:

Configuration

Typical configuration topics for a PWA include:

Usage, tips and tricks

Coding tips and tricks

See also