Progressive Web Apps for Ecommerce: Do You Still Need One in 2026?

A progressive web app is a website that installs to a phone’s home screen, works offline, and can send push notifications, all without an app store. For ecommerce the appeal is obvious: one codebase, no 30% app store cut, and instant updates. But the pitch has been oversold for years, and in 2026 the honest answer is “it depends on your traffic and your catalog.”

I build and maintain ecommerce sites for a living, mostly for small and mid-sized businesses around New York, and I’ve talked more people out of PWAs than into them. Here’s how to tell which side of that line you’re on.

What a PWA actually is (and isn’t)

A PWA is not a framework. It’s a set of browser capabilities you opt into on top of a normal website. The three that matter for stores:

• A web app manifest. A JSON file that tells the browser your app’s name, icons, theme colors, and whether it opens fullscreen.
• A service worker. A background script that intercepts network requests so you can cache assets, serve pages offline, and handle flaky connections.
• HTTPS. Non-negotiable. Service workers won’t register on plain HTTP.

That’s it. Push notifications and install prompts are layered on top of those. If someone tells you a PWA is a separate product you buy, they’re selling you something.

Where PWAs genuinely help an ecommerce store

1. Repeat customers on mobile

This is the real win. A first-time visitor will not install your store. A customer on their fourth order who orders from their phone every month absolutely might. The install prompt turns a bookmark they’d never make into an icon next to Instagram. For stores with strong repeat purchase behavior (coffee, supplements, pet food, local delivery), that’s worth real money.

2. Slow or unreliable connections

A well-built service worker serves your shell and cached product pages instantly, then revalidates in the background. On a spotty connection, a PWA feels dramatically faster than a plain site. If a chunk of your traffic is mobile and not on great wifi, this matters.

3. Push notifications you actually control

No app store review, no developer account fee, no waiting on approval. You write the notification, you send it. The catch is on iOS, and it’s a big one, so let’s get to that.

The 2026 reality check: iOS

For years the standard line was “PWAs barely work on iPhone.” That’s out of date, but not in the way people assume. As of 2026, iOS supports web push and home screen installs, but only when the user adds the site to their home screen first. Safari will not show a native install banner the way Chrome on Android does. You have to teach the user how to do it, usually with a small prompt explaining the Share > Add to Home Screen steps.

So on iOS you get the features, but you have to earn the install manually. That changes the math: if most of your customers are on iPhone, your install rate will be lower than the Android side, and you should plan for that instead of being surprised by it.

A minimal, correct service worker

Most “PWA plugins” generate bloated service workers that cache everything and break your checkout when prices change. Don’t cache everything. Cache the shell and static assets, and always let product, cart, and checkout requests hit the network.

// sw.js
const CACHE = 'store-shell-v3';
const SHELL = ['/', '/offline.html', '/css/site.css', '/js/site.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;
 const url = new URL(request.url);

 // Never cache anything transactional or cross-origin.
 if (
 request.method !== 'GET' ||
 url.origin !== self.location.origin ||
 //(cart|checkout|account|api)b/.test(url.pathname)
 ) {
 return; // let the browser handle it normally
 }

 // Stale-while-revalidate for everything else.
 event.respondWith(
 caches.match(request).then((cached) => {
 const network = fetch(request)
 .then((response) => {
 if (response.ok) {
 const copy = response.clone();
 caches.open(CACHE).then((cache) => cache.put(request, copy));
 }
 return response;
 })
 .catch(() => cached || caches.match('/offline.html'));
 return cached || network;
 })
 );
});

Note the early return for cart, checkout, account, and API routes. That single guard prevents the most common PWA bug in ecommerce: a customer adding an item, going offline briefly, and seeing a cached cart that no longer matches reality.

Your manifest, minus the junk

{
 "name": "Your Store",
 "short_name": "Store",
 "start_url": "/?utm_source=pwa",
 "scope": "/",
 "display": "standalone",
 "background_color": "#ffffff",
 "theme_color": "#111111",
 "icons": [
 { "src": "https://i0.wp.com/www.kennykey.com/icons/192.png", "sizes": "192x192", "type": "image/png" },
 { "src": "https://i0.wp.com/www.kennykey.com/icons/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" }
 ]
}

The start_url with a UTM parameter is a small trick worth keeping. It lets your analytics separate PWA launches from regular browser visits, so you can measure whether the install prompt is actually paying off instead of guessing.

When a PWA is the wrong call

Skip it if any of these describe you:

• Most of your traffic is first-time, single-purchase. Nobody installs a store they’ll never use again. You’d be adding maintenance for nothing.
• You need hardware APIs. Bluetooth, NFC, background geofencing, and deep camera control are still native territory. A PWA won’t get you there.
• Your team can’t maintain it. A service worker is code that runs forever in the background. If nobody on your team knows what a cache version is, you’re one bad deploy away from customers seeing stale prices.
• You already have a solid native app. Building a second install path just splits your audience.

For a lot of stores, the better investment is plain performance work: image optimization, fixing layout shift, cutting render-blocking JavaScript. Those help every visitor, not just the ones who install. That kind of groundwork is most of what custom web development actually consists of, and it tends to beat a PWA on ROI until you have a real repeat-customer base.

How to decide

Pull your own numbers first. What percentage of your revenue comes from returning customers on mobile? What’s your mobile conversion rate versus desktop? If repeat mobile buyers are more than roughly a fifth of your revenue, a PWA is worth prototyping. If they’re a sliver, fix your Core Web Vitals instead and revisit next year.

Don’t let anyone sell you a PWA as a checkbox. It’s a bet on your customer behavior, and your analytics already know the answer.

FAQ

Do PWAs work on iPhone in 2026?

Yes, including web push, but only after the user manually adds the site to their home screen through Safari’s Share menu. There’s no automatic install banner on iOS, so your install rate there will be lower than on Android.

Can I replace my native app with a PWA?

For a store that mainly needs browsing, cart, checkout, and notifications, often yes. If you rely on Bluetooth, NFC, background location, or heavy camera features, no. Those still require native code.

Will a PWA hurt my SEO?

No. A PWA is still a normal crawlable website. If anything, the performance gains from good caching can help your rankings. Just make sure your service worker never serves stale product or pricing pages to search engines.