Progressive Web Apps [2026]: PWA Guide for Developers

Progressive Web Apps occupy a compelling position in 2026: they give web applications access to device capabilities that were previously exclusive to native apps, without requiring users to go through the App Store or Play Store.

This is increasingly important as App Store fees (15-30% of revenue) and approval delays frustrate developers, and as browsers have expanded the APIs available to web apps. In 2026, PWAs can access camera, microphone, location, Bluetooth, push notifications, background sync, and file system access — a capability set that was exclusive to native apps as recently as 2020.

What Is a PWA in 2026?

A Progressive Web App (PWA) is a web application that uses a set of modern browser APIs to deliver app-like experiences: it can be installed to the home screen, works offline, receives push notifications, and runs in full-screen mode without browser UI — while remaining a standard website accessible through a URL.

The three technical components that define a PWA:

1. Web App Manifest: A JSON file that tells the browser how to display the app when installed — name, icon, theme color, start URL, and display mode (standalone removes browser UI).
2. Service Worker: A JavaScript worker that runs in the background, intercepts network requests, and serves cached responses for offline support.
3. HTTPS: PWAs require a secure origin. Service workers do not register on HTTP pages.

Browser support for PWA installation: Chrome (desktop and Android), Edge, Samsung Internet, and Safari (iOS 16.4+, desktop macOS) all support PWA installation. Firefox does not currently support the install prompt. The iOS PWA experience is more limited than Android — no push notifications in Safari until iOS 16.4, and some storage quotas are lower.

Web App Manifest: Make It Installable

The web app manifest is a JSON file that describes how your app should appear and behave when installed. Link it from your HTML with <link rel="manifest" href="/manifest.json">.

{
  "name": "My App",
  "short_name": "MyApp",
  "description": "A short description of what it does",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0070f3",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

The display: standalone setting removes the browser address bar and navigation buttons, making the installed app look like a native application. Generate icons in all required sizes using tools like RealFaviconGenerator or the PWA Asset Generator.

Chrome shows an install prompt when a site meets the PWA installability criteria: HTTPS, valid manifest with required fields, and a registered service worker. The beforeinstallprompt event lets you intercept and customize the install prompt timing.

Service Workers: The Core of PWA

A service worker is a JavaScript script that runs in the browser background, separate from the web page. It can intercept all network requests from your app, serve cached responses, and receive push notifications — even when no browser tab is open.

Service worker registration:

// In your main app code
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(reg => console.log('SW registered', reg))
    .catch(err => console.error('SW error', err))
}

Service worker lifecycle: Install (triggered when the browser installs a new version of the SW — good time to pre-cache critical resources), Activate (cleanup old caches), Fetch (intercept network requests and return cached or network responses).

Use Workbox from Google to handle service worker caching without writing low-level service worker code:

// sw.js with Workbox
import { registerRoute } from 'workbox-routing'
import { CacheFirst, NetworkFirst } from 'workbox-strategies'

// Cache images with Cache First strategy
registerRoute(
  ({ request }) => request.destination === 'image',
  new CacheFirst({ cacheName: 'images' })
)

// Cache API responses with Network First
registerRoute(
  ({ url }) => url.pathname.startsWith('/api/'),
  new NetworkFirst({ cacheName: 'api-cache' })
)

PWA vs Native App: When to Choose Each

The choice between PWA and native app (React Native, Flutter, Swift/Kotlin) depends on your feature requirements, distribution strategy, and team expertise.

Choose PWA if: Your app is content-focused, does not require advanced hardware APIs (AR, complex Bluetooth), you want to avoid App Store fees, or you need one codebase for web + installed app.

Choose native if: You need the best possible performance for graphics or games, require full hardware API access, or your target audience expects an App Store-distributed app.

Frequently Asked Questions

Can a PWA replace a native app?

For most business applications — productivity tools, content apps, e-commerce, SaaS products — a well-built PWA can replace a native app and often provides a better user experience due to lower installation friction. For games, apps that require advanced AR/VR capabilities, or apps that need deep OS integration (background processing, specialized hardware), native apps still have significant advantages.

Do PWAs work on iOS?

Yes, with limitations. Safari on iOS 16.4+ supports push notifications and improved PWA capabilities. Earlier iOS versions have more restricted PWA support — no push notifications, stricter storage quotas, and limited background processing. The iOS PWA gap with Android has narrowed significantly since iOS 16.4 but has not fully closed. Test your PWA thoroughly on actual iOS devices.

What is a service worker and do I need one?

A service worker is a JavaScript file that runs in the background and intercepts network requests from your web app. You need one to: make your app work offline, implement background sync, or receive push notifications. You do not need one for a basic installable PWA — the manifest and HTTPS are sufficient for the install prompt. But offline support requires a service worker.

What cache strategy should I use for my service worker?

Common Workbox strategies: Cache First (serve from cache, update in background) for static assets that rarely change. Network First (try network, fall back to cache) for API responses where freshness matters. Stale While Revalidate (serve cached immediately, update cache in background) for non-critical assets where slightly stale data is acceptable. Most apps use a mix of strategies depending on the resource type.

Note: Information in this article reflects the state of the field as of early 2026.