PWA in 2026: Are Progressive Web Apps Still Worth It?

PWA working across mobile and desktop

When PWAs first gained traction around 2016-2018, there was serious hype. "They'll replace native apps." Nearly a decade later, native apps are alive and well on the app stores, and PWAs didn't take over the world. But they didn't die either. In certain niches, they've become the more practical choice.

Quick PWA Refresher

Progressive Web App. Built with web technologies (HTML, CSS, JavaScript) but behaves like a native app. Three core capabilities:

Installable. Add to the home screen and run as a standalone app. No browser chrome, full-screen experience.

Offline capable. Service Workers cache resources so basic functionality works without a network connection.

Push notifications. The server can send notifications even when the app is closed.

The technical building blocks: manifest.json and Service Workers.

manifest.json

A JSON file defining app metadata — name, icons, start URL, theme color, display mode, screen orientation.

{
  "name": "WebPiki",
  "short_name": "WebPiki",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#3b82f6",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

display: "standalone" makes it look like a native app without browser UI. fullscreen hides even the status bar — better for games.

Link it in HTML:

<link rel="manifest" href="/manifest.json">

Service Workers

The engine of PWA. A JavaScript worker that acts as a proxy between the browser and the network. Runs on a separate thread from the main page, intercepts network requests, returns cached resources, handles background sync, and receives push notifications.

// sw.js — basic Service Worker
const CACHE_NAME = "v1";
const ASSETS = ["/", "/offline.html", "/styles.css", "/app.js"];

// Cache core resources on install
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(ASSETS))
  );
});

// Intercept fetch requests
self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      return cached || fetch(event.request);
    })
  );
});

Caching strategies:

Cache First — Serve from cache, fall back to network. Good for static assets (images, fonts, CSS)
Network First — Try network, fall back to cache. Good for dynamic data like API responses
Stale While Revalidate — Serve cached version immediately, update cache in the background. Good for feeds or listings

Google's Workbox library lets you configure these strategies declaratively, which beats writing Service Workers from scratch.

Browser Support in 2026

iOS was the biggest PWA roadblock for years. That's improved significantly.

Chrome/Edge/Samsung Internet — Full PWA support. Install, offline, push notifications all work.

Safari (iOS) — After years of dragging its feet, Safari has caught up on the basics. Push notifications landed in iOS 16.4 (2023), and home screen installation works. Some constraints remain:

No Web Bluetooth or Web USB
Limited background sync
Partial Badge API support
PWA storage can get evicted after periods of inactivity

These iOS limitations mean "fully replace native with PWA" is still hard. But the fundamentals — offline, install, push — work on all major browsers, which covers most use cases.

PWA vs Native vs Cross-Platform

When you decide to build an app, there are several paths. Here's how they stack up.

Native (Swift/Kotlin)

Best performance. Full hardware access
App Store distribution. Users perceive it as "a real app"
Requires separate iOS and Android development. Double the cost
Every update goes through store review

Cross-Platform (React Native, Flutter)

One codebase for iOS + Android
Near-native performance and UX
Platform-specific code still needed for native modules
App Store distribution

PWA

Web tech only. Any web developer can start immediately
Accessible via URL without installation. Installation optional
Updates deploy instantly. No store review
Limited hardware access. Performance ceiling
Not in app stores (though TWA wrapping for Google Play is possible)

None of these is universally better. It depends on the project.

When PWAs Make Sense

Content-driven services. News, blogs, e-commerce catalogs. No complex native features needed, content accessibility matters most. Twitter's (now X) PWA and Starbucks PWA are well-known success stories.

Emerging markets. Low-end devices, unreliable networks. PWAs are small and work offline, which gives them an edge in these environments. That's why services targeting India and Africa have adopted PWAs heavily.

Internal/B2B tools. No reason to put internal employee tools on an app store. Share a URL, install to home screen if needed. Updates deploy instantly with no review process.

Prototyping. Validating an idea quickly. Deploy with a URL, no store review wait. If it gets traction, build native later.

Budget constraints. A web team can build it. No need to hire separate iOS and Android native developers.

PWA Limitations

Being honest about the downsides:

Performance. Graphics-heavy games or video editing don't work well as PWAs. WebGL and WebGPU have improved things, but the native gap exists.

Hardware access. NFC, Bluetooth, biometric auth — PWA support is limited. Web Bluetooth API exists but browser support is spotty.

No app store presence. Users discover apps through app stores. A PWA misses that marketing channel. Google Play accepts TWA-wrapped PWAs, but Apple's App Store policies are stricter.

iOS constraints. Safari's limitations around background processing and certain APIs create a noticeable gap vs native on Apple devices.

User perception. "Install the app" and "Add to home screen" feel different to users. The PWA installation flow isn't intuitive, leading to lower install conversion rates.

Success Stories

Twitter Lite (now X) — 70% reduction in data usage, 30% faster page loads after PWA switch
Starbucks — Offline menu browsing. 99.84% smaller than the native app
Pinterest — 40% increase in user engagement after mobile web → PWA conversion
Trivago — 150% increase in user engagement post-PWA

Some companies tried PWA and went back to native. Usually because they needed native-level UX that PWA couldn't deliver — payment processing, heavy camera usage, location-dependent features.

Adding PWA to a Next.js Project

The setup is straightforward. The next-pwa package automates Service Worker generation.

npm install next-pwa

// next.config.js
const withPWA = require("next-pwa")({
  dest: "public",
  disable: process.env.NODE_ENV === "development",
});

module.exports = withPWA({
  // existing Next.js config
});

Put manifest.json in the public/ folder, link it in your document, and the basics are done. Disabling the Service Worker in development mode prevents caching headaches.

Should You Pick PWA in 2026?

It depends on the situation.

If you already have a web tech stack, don't need deep hardware access, and prioritize fast deployment and broad accessibility — PWA is still a strong option. iOS support improvements have widened the range of practical use cases.

If app store visibility matters or complex native features are essential, React Native or Flutter is a better fit. And if budget and timeline allow, native is always on the table.

PWA didn't replace native apps. That doesn't mean it failed. It carved out a practical niche — combining the web's strengths (accessibility, link sharing, instant updates) with app-like capabilities (install, offline, notifications). Not right for every project, but very efficient for the right ones.