Progressive Web Apps bridge the gap between websites and native mobile applications. They load in a browser like any website but offer capabilities that were once exclusive to platform-specific apps: offline functionality, push notifications, home screen installation, and background synchronization. PWAs use standard web technologies — HTML, CSS, JavaScript — enhanced by modern browser APIs to deliver native-quality experiences without requiring app store distribution.
Google engineers Alex Russell and Frances Berriman coined the term “Progressive Web App” in 2015. Since then, PWA capabilities have expanded steadily across browsers. Chrome, Edge, Firefox, and Safari all support the core PWA features, though the level of support varies. The gap between what web apps and native apps can do has narrowed to the point where PWAs are a legitimate choice for most mobile-first projects.
What Makes a Progressive Web App
A PWA is defined by three technical requirements and a set of progressive enhancement principles:
Three Core Requirements
- HTTPS — Service workers require a secure context. Your site must be served over HTTPS (localhost is exempted during development)
- Service Worker — A JavaScript file that runs in the background, independent of the web page. It intercepts network requests, manages caching, and enables offline functionality
- Web App Manifest — A JSON file that tells the browser how to display your app when installed: name, icons, theme color, display mode, and start URL
Progressive Enhancement Principles
- Progressive — Works for every user regardless of browser. Enhanced features activate when the browser supports them
- Responsive — Adapts to any screen size and orientation using responsive design techniques
- Connectivity-independent — Functions offline or on unreliable networks through service worker caching
- App-like — Uses the app shell model to feel and navigate like a native application
- Installable — Users can add the app to their home screen without visiting an app store
- Linkable — Shareable via URL, no complex installation required
The Web App Manifest
The manifest file controls how your PWA appears when installed on a device. It defines the app name, icons, theme colors, and display behavior.
{
"name": "TaskFlow — Project Management",
"short_name": "TaskFlow",
"description": "Lightweight project management for agile teams",
"start_url": "/app/",
"scope": "/app/",
"display": "standalone",
"orientation": "any",
"background_color": "#ffffff",
"theme_color": "#c2724e",
"icons": [
{
"src": "/icons/icon-72.png",
"sizes": "72x72",
"type": "image/png"
},
{
"src": "/icons/icon-192.png",
"sizes": "192x192",
"type": "image/png",
"purpose": "any maskable"
},
{
"src": "/icons/icon-512.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any maskable"
}
],
"screenshots": [
{
"src": "/screenshots/dashboard.png",
"sizes": "1280x720",
"type": "image/png",
"form_factor": "wide",
"label": "Project dashboard"
},
{
"src": "/screenshots/mobile-tasks.png",
"sizes": "750x1334",
"type": "image/png",
"form_factor": "narrow",
"label": "Task list on mobile"
}
]
}Link the manifest from your HTML head:
<link rel="manifest" href="/manifest.json">
<meta name="theme-color" content="#c2724e">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="default">The display field determines how the app runs after installation. standalone hides the browser’s address bar and tab interface, making the app look native. fullscreen removes all browser UI. minimal-ui keeps a small navigation bar. browser opens in a regular browser tab.
Service Workers: The Engine Behind PWAs
Service workers are the most powerful and complex part of PWA development. A service worker is a JavaScript file that the browser runs in a separate thread, independent of the web page. It acts as a programmable network proxy — every HTTP request from your app passes through the service worker, which can cache responses, serve cached content when offline, and manage background tasks.
Registration
// main.js — Register the service worker
if ('serviceWorker' in navigator) {
window.addEventListener('load', async () => {
try {
const registration = await navigator.serviceWorker.register('/sw.js', {
scope: '/'
});
console.log('SW registered:', registration.scope);
} catch (error) {
console.error('SW registration failed:', error);
}
});
}Install Event: Pre-caching Critical Assets
// sw.js
const CACHE_NAME = 'taskflow-v2';
const PRECACHE_ASSETS = [
'/',
'/app/',
'/css/main.css',
'/js/app.js',
'/js/vendor.js',
'/fonts/space-grotesk-var.woff2',
'/images/logo.svg',
'/offline.html'
];
self.addEventListener('install', (event) => {
event.waitUntil(
caches.open(CACHE_NAME)
.then(cache => cache.addAll(PRECACHE_ASSETS))
.then(() => self.skipWaiting())
);
});Activate Event: Cleaning Old Caches
self.addEventListener('activate', (event) => {
event.waitUntil(
caches.keys().then(cacheNames => {
return Promise.all(
cacheNames
.filter(name => name !== CACHE_NAME)
.map(name => caches.delete(name))
);
}).then(() => self.clients.claim())
);
});Fetch Event: Caching Strategies
The fetch event handler determines how your app responds to network requests. Different caching strategies suit different content types:
self.addEventListener('fetch', (event) => {
const { request } = event;
const url = new URL(request.url);
// Strategy 1: Cache First (static assets)
if (request.destination === 'style' ||
request.destination === 'script' ||
request.destination === 'font') {
event.respondWith(
caches.match(request).then(cached => {
return cached || fetch(request).then(response => {
const clone = response.clone();
caches.open(CACHE_NAME).then(cache => cache.put(request, clone));
return response;
});
})
);
return;
}
// Strategy 2: Network First (API calls, dynamic content)
if (url.pathname.startsWith('/api/')) {
event.respondWith(
fetch(request)
.then(response => {
const clone = response.clone();
caches.open(CACHE_NAME).then(cache => cache.put(request, clone));
return response;
})
.catch(() => caches.match(request))
);
return;
}
// Strategy 3: Stale While Revalidate (pages)
event.respondWith(
caches.match(request).then(cached => {
const fetchPromise = fetch(request).then(response => {
const clone = response.clone();
caches.open(CACHE_NAME).then(cache => cache.put(request, clone));
return response;
});
return cached || fetchPromise;
}).catch(() => caches.match('/offline.html'))
);
});Push Notifications
Push notifications let your PWA re-engage users even when the app is not open. The implementation involves three parts: requesting permission, subscribing to push events, and handling incoming notifications in the service worker.
// Request notification permission and subscribe
async function subscribeToPush() {
const permission = await Notification.requestPermission();
if (permission !== 'granted') return;
const registration = await navigator.serviceWorker.ready;
const subscription = await registration.pushManager.subscribe({
userVisibleOnly: true,
applicationServerKey: urlBase64ToUint8Array(VAPID_PUBLIC_KEY)
});
// Send subscription to your server
await fetch('/api/push/subscribe', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(subscription)
});
}
// Handle push events in the service worker
// sw.js
self.addEventListener('push', (event) => {
const data = event.data.json();
event.waitUntil(
self.registration.showNotification(data.title, {
body: data.message,
icon: '/icons/icon-192.png',
badge: '/icons/badge-72.png',
data: { url: data.actionUrl },
actions: [
{ action: 'open', title: 'View' },
{ action: 'dismiss', title: 'Dismiss' }
]
})
);
});
self.addEventListener('notificationclick', (event) => {
event.notification.close();
if (event.action === 'open' || !event.action) {
event.waitUntil(clients.openWindow(event.notification.data.url));
}
});Background Sync
Background Sync lets your PWA defer actions until the user has a stable internet connection. If a user submits a form while offline, Background Sync queues the request and retries automatically when connectivity returns.
// Queue a sync event when offline
async function saveData(data) {
try {
await fetch('/api/tasks', {
method: 'POST',
body: JSON.stringify(data)
});
} catch {
// Network failed — store locally and register sync
await saveToIndexedDB('pending-tasks', data);
const registration = await navigator.serviceWorker.ready;
await registration.sync.register('sync-tasks');
}
}
// sw.js — Handle the sync event
self.addEventListener('sync', (event) => {
if (event.tag === 'sync-tasks') {
event.waitUntil(syncPendingTasks());
}
});
async function syncPendingTasks() {
const tasks = await getFromIndexedDB('pending-tasks');
for (const task of tasks) {
await fetch('/api/tasks', {
method: 'POST',
body: JSON.stringify(task)
});
await removeFromIndexedDB('pending-tasks', task.id);
}
}The App Shell Architecture
The app shell model separates your application’s UI skeleton from its content. The shell — header, navigation, footer, layout containers — is cached during the service worker install event. Content loads dynamically into the shell from APIs or the cache. This produces near-instant loading on repeat visits because the browser renders the cached shell immediately while content streams in.
This pattern works particularly well with single-page application frameworks. React, Vue, and Angular applications already separate the app shell from content by design. Adding a service worker that caches the shell turns these SPAs into installable, offline-capable PWAs.
Installation and the Install Prompt
When a PWA meets Chrome’s installability criteria (valid manifest, registered service worker, HTTPS), the browser fires a beforeinstallprompt event. You can intercept this event to show a custom install prompt at the right moment in the user journey.
let deferredPrompt;
window.addEventListener('beforeinstallprompt', (event) => {
event.preventDefault();
deferredPrompt = event;
showInstallButton();
});
async function handleInstallClick() {
if (!deferredPrompt) return;
deferredPrompt.prompt();
const { outcome } = await deferredPrompt.userChoice;
console.log('Install outcome:', outcome);
deferredPrompt = null;
hideInstallButton();
}On iOS, Safari supports PWA installation through “Add to Home Screen” but does not fire the beforeinstallprompt event. You need to detect iOS and show manual installation instructions.
PWA Frameworks and Tools
Writing service workers from scratch is educational but error-prone. Production PWAs typically use a library to manage caching and updates:
- Workbox (Google) — The standard library for service worker caching strategies. Provides pre-caching, runtime caching, background sync, and routing with a clean API
- Vite PWA Plugin — Zero-config PWA support for Vite-based projects. Generates service workers and manifests automatically during the build step
- Next.js PWA — next-pwa integrates Workbox with Next.js, adding offline support to server-rendered and statically generated Next.js applications
- Serwist — A modern, actively maintained fork of Workbox with TypeScript-first API and smaller bundle size
Advantages Over Native Apps
- No app store gatekeeping — Deploy updates instantly. No review process, no approval delays, no 30% commission on in-app purchases
- Instant access — Users visit a URL and start using the app. The installation step is optional and adds the icon to their home screen
- Automatic updates — Service worker updates deploy with your next build. Users always run the latest version
- Discoverability — Search engines index PWAs like regular websites. Your app appears in search results alongside your content
- Cross-platform from a single codebase — One codebase runs on Android, iOS, Windows, macOS, Linux, and Chrome OS
- Smaller footprint — A PWA typically weighs kilobytes to a few megabytes, compared to tens or hundreds of megabytes for native apps
Current Limitations
- iOS restrictions — Safari’s PWA support lags behind Chrome. Push notifications on iOS arrived only in iOS 16.4 and require the app to be installed. Background processing is limited
- Hardware access — Bluetooth, NFC, and certain sensor APIs are limited or unavailable in some browsers. Native apps still have deeper hardware integration
- App store presence — Some users expect to find apps in the App Store or Play Store. Tools like PWABuilder and Bubblewrap can wrap PWAs for store distribution
- Storage limits — Browsers impose cache storage limits that vary by platform. Heavy offline-first apps may hit these boundaries
Testing and Debugging PWAs
Chrome DevTools provides dedicated tooling for PWA development. The Application panel shows your manifest, service worker status, cache contents, and IndexedDB storage. Lighthouse generates a PWA audit that checks installability, offline support, and performance metrics.
Frequently Asked Questions
Do PWAs work on iPhones?
Yes, with caveats. Safari supports service workers, offline caching, and home screen installation. Push notifications arrived in iOS 16.4 for installed PWAs. However, iOS still lacks support for some features like Background Sync and badging. The experience is functional but not as complete as on Android or desktop Chrome.
Can a PWA replace a native app?
For content-driven apps, e-commerce, dashboards, and productivity tools — absolutely. Major companies including Starbucks, Pinterest, and Uber have shipped PWAs that match or exceed their native counterparts in engagement metrics. For apps that require deep hardware integration (camera processing, Bluetooth peripherals, ARKit) or need App Store discoverability, native development still holds advantages.
How do PWAs affect SEO?
PWAs are regular web pages that search engines crawl and index normally. The service worker and manifest add functionality without changing how search engines see your content. Fast loading times and good accessibility — both natural PWA benefits — positively impact search rankings. You can use modern development tools to audit both your PWA features and SEO performance simultaneously.
What is the minimum browser support for PWAs?
Service workers are supported in all modern browsers: Chrome, Firefox, Edge, Safari, and Opera. The manifest specification is also widely supported. Feature detection ensures graceful degradation — browsers that do not support PWA features simply run the application as a standard website. This progressive enhancement approach means you never break the experience for any user.
PWAs represent the convergence of web and native platforms. As browser capabilities continue to expand and the web platform matures, the line between “website” and “app” will keep blurring. For teams that already build for the web, adding PWA capabilities to an existing responsive web application is one of the highest-impact improvements available — turning a page visitors leave into an app they keep.
