Progressive Web Apps in 2026: When Your Site Should Be One (and When It Shouldn’t)

A progressive web app is just a website that behaves more like an installed app: it works offline, loads fast on repeat visits, and can live on a phone’s home screen. That’s the whole idea. The marketing around PWAs has always been louder than the technology, so here’s what’s actually true in 2026 and how to decide if it’s the right call for your site.

What a PWA actually is (stripped of the buzzwords)

There’s no single “PWA” switch you flip. A PWA is a normal website plus a few browser capabilities layered on top:

• A web app manifest so the browser knows the name, icons, and how it should launch.
• A service worker that sits between your page and the network, caching assets and controlling offline behavior.
• HTTPS, because none of this works without it.
• Responsive layout, since these get installed on phones.

That’s it. Everything else people attach to the term (push notifications, install prompts, app-store listings) is optional and depends on the browser.

The install story in 2026

This is where most old PWA articles are flat-out wrong. The landscape shifted:

• Chrome and Edge on desktop and Android still support the install prompt through the beforeinstallprompt event. You can trigger your own “Add to home screen” UI.
• Safari on iOS does not fire beforeinstallprompt. Users install via the Share menu, and you have to walk them through it with your own instructions. This has been true for years and hasn’t changed.
• iOS web push works now, but only for apps the user has added to the home screen, and it requires a permission gesture. It is not the same as native push.
• App store distribution is real but clunky. You can wrap a PWA for the Play Store, and Microsoft accepts PWAs in its store. Apple does not, so iOS users install through the browser or not at all.

If your audience is heavily iOS, plan for a worse install experience than the Android crowd gets. That’s not a reason to skip PWAs, it’s a reason to set expectations.

A minimal, working setup

Here’s a manifest. Keep it simple and honest about what your app does.

{
 "name": "Harbor Coffee Ordering",
 "short_name": "Harbor",
 "start_url": "/order/",
 "display": "standalone",
 "background_color": "#ffffff",
 "theme_color": "#1f2937",
 "icons": [
 { "src": "https://i0.wp.com/www.kennykey.com/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
 { "src": "https://i0.wp.com/www.kennykey.com/icons/icon-512.png", "sizes": "512x512", "type": "image/png" },
 { "src": "https://i0.wp.com/www.kennykey.com/icons/maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
 ]
}

Link it in your HTML head:

<link rel="manifest" href="/manifest.webmanifest">
<meta name="theme-color" content="#1f2937">

Now the service worker. The mistake I see most often is people cache everything on install, which bloats the first load and breaks when you deploy. Cache the shell, fetch the rest on demand, and version your cache name so old caches get cleaned up.

const CACHE = 'shell-v3';
const SHELL = ['/', '/offline/', '/css/app.css', '/js/app.js'];

self.addEventListener('install', (event) => {
 event.waitUntil(
 caches.open(CACHE).then((cache) => cache.addAll(SHELL))
 );
 self.skipWaiting();
});

self.addEventListener('activate', (event) => {
 event.waitUntil(
 caches.keys().then((keys) =>
 Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k)))
 )
 );
 self.clients.claim();
});

self.addEventListener('fetch', (event) => {
 const { request } = event;
 if (request.method !== 'GET') return;

 // Network-first for pages, cache-first for static assets
 if (request.mode === 'navigate') {
 event.respondWith(
 fetch(request).catch(() => caches.match('/offline/'))
 );
 return;
 }

 event.respondWith(
 caches.match(request).then((cached) => cached || fetch(request))
 );
});

Register it from your main script:

if ('serviceWorker' in navigator) {
 window.addEventListener('load', () => {
 navigator.serviceWorker.register('/sw.js');
 });
}

That’s a real, deployable foundation. Notice I’m not caching API responses blindly. For anything dynamic, decide per route whether you want stale-while-revalidate or straight network-first. Guessing here is how you ship stale prices to customers.

When a PWA is the right answer

• You already have a solid responsive site and want offline access or a home-screen presence without building two separate codebases.
• Your users return often: ordering, scheduling, field tools, dashboards, internal apps.
• You’re budget-constrained. One codebase beats maintaining iOS and Android apps, especially for a small business.
• Your content is read-heavy and benefits from instant repeat loads.

When it isn’t

• You need deep native features: background location, Bluetooth, heavy camera work, complex file access. Web APIs cover more than they used to, but native still wins here.
• Your audience lives on iOS and expects the App Store. You’ll fight the install flow every time.
• Your site is a marketing brochure. A fast, well-built site already does the job. Adding a service worker you don’t maintain is a liability, not a feature.
• You can’t commit to maintaining it. Service workers are cached aggressively. Ship a bug and users can be stuck on a broken version until you push a fix and they reload twice.

The Long Island angle, briefly

I build sites for businesses around Commack and the rest of the Island, and the PWA question comes up most with service businesses and local retailers. The honest answer for most of them is: fix your mobile performance and layout first. A slow site with a service worker is still a slow site. If you want a straight assessment of whether a PWA makes sense for what you actually do, that’s part of the work I do as a Long Island web design practice. No upsell to an app you don’t need.

Testing before you ship

Don’t trust the install prompt on your own phone. Check these:

• Run Lighthouse in Chrome DevTools. The PWA checks will tell you if the manifest and service worker are wired correctly.
• Test offline by toggling network throttling to “Offline” and reloading. See what actually breaks.
• Test on a real iPhone through Safari. The install flow is different and you’ll want screenshots for your instructions.
• Deploy a change and confirm the update actually reaches users. Watch for the “waiting to activate” state.

FAQ

Do I need a PWA if I already have a mobile app?

Usually not. If you have a native app people actually use, a PWA mostly adds maintenance overhead. It makes sense if you want a lightweight web entry point for people who won’t download anything.

Will a PWA get me into the App Store?

No. Apple doesn’t accept PWAs. Google Play and the Microsoft Store do, with some wrapping. On iOS, users install through Safari’s Share menu.

Is a PWA faster than a regular website?

Only after the first visit. The service worker caches assets so repeat loads are near-instant. The first load is the same as any other site, so your underlying performance still matters.