PWA Myths Debunked¶

Most arguments about Progressive Web Apps are built on facts that were true at some point: "iOS doesn't support push" (true until 2023), "you need a service worker to install" (true in Chrome until 2023), "Safari deletes your data after seven days" (partly true, with exceptions most people miss). This post takes twelve of the most repeated claims and checks each one against the specifications, browser source code, release notes and MDN's compatibility data as of September 2026. Some are simply wrong, some are outdated, and a few are half right in ways that matter for how you build.

The myths at a glance¶

Myth 1: "PWAs are dead"¶

The claim. Google stopped caring about PWAs, Lighthouse removed its PWA score, and Apple never wanted them anyway.

The evidence. The Lighthouse change is real: Lighthouse 12.0.0 (April 22, 2024) removed the PWA category. The stated reason was Chrome's updated installability criteria, not a change in direction for the platform. Auditing PWAs After Lighthouse Dropped the PWA Category covers the details. What the three engines have shipped since then points the other way:

• Chromium. Chrome 144 (January 2026) removed the once-a-day throttle on manifest update checks and made name and icon changes an optional Review app update item instead of a blocking dialog. Chrome 150 (June 2026) shipped migrate_from and migrate_to, so an installed app can move to a new origin within the same site. Chrome 152 (August 2026) made notifications from installed PWAs on macOS appear under the app's own name and icon instead of "Google Chrome". And Chrome Platform Status lists the Web Install API (navigator.install()) and the <install> element as preparing to ship on desktop in Chrome 156.
• WebKit. Safari 18.4 (March 2025) added Declarative Web Push. Safari 26.0 (September 15, 2025) made every site added to the Home Screen open as a web app by default, stating that "there are now zero requirements for 'installability' in Safari". Safari 27 added the service worker Static Routing API.
• Gecko. Firefox 143 (September 16, 2025) let Windows users pin sites to the taskbar as web apps, and Firefox 150 (April 21, 2026) extended that to the Microsoft Store build.

Verdict: false. The word "PWA" appears less in marketing than it did in 2018. The platform features keep shipping, in all three engines. The State of PWAs in 2026 goes through them in detail.

Myth 2: "The iPhone doesn't support PWAs"¶

The claim. Apple blocks web apps on iOS to protect the App Store.

The evidence. iOS support arrived late and in steps, and it still has gaps, but "doesn't support" has been wrong for years:

What's still missing on iOS is real and worth planning for: there's no beforeinstallprompt or other install API, so you can only show instructions. There's no Background Sync, Periodic Background Sync or Background Fetch (MDN lists all three as Chromium-only). File Handling, Share Target and protocol handlers from the manifest aren't supported. And in the EU, the iOS 17.4 betas briefly removed Home Screen web apps before Apple reversed the decision for the release.

Verdict: outdated. iOS supports the core of a PWA (offline, installation to the Home Screen, push, badging) with a smaller set of integrations than Chromium. iOS & iPadOS covers every difference, and Web Push on iOS & Safari the push-specific rules.

Myth 3: "You need a service worker to be installable"¶

The claim. To get an install prompt, you need a service worker with a fetch handler, so every PWA starts with an (often empty) fetch listener.

The evidence. This was Chrome's rule for years, and it's why so many sites shipped self.addEventListener("fetch", () => {}). Chrome changed it. Revisiting Chrome's installability criteria (December 2023) says Chrome removed the requirement "to have a service worker that implements the fetch() method for installation from the menu, since version 108 on mobile and 112 on Desktop", and launched "a default custom page for sites that don't implement their own" offline page. At the time, the post noted that the algorithm behind the automatic install prompt still required a fetch handler. Installability Criteria documents that current Chromium's install pipeline has no service worker check at all, verified with test pages in Chrome 153 that fired beforeinstallprompt without registering a worker.

The other engines never required one. On iOS, WebKit says Home Screen web apps "never required Service Workers", and since Safari 26 there are "zero requirements" for installability. Firefox for Android's install criteria (a manifest with a name, a display other than browser, and an icon of at least 192 px) don't include a worker either.

Why you still want one. A worker is what makes an installed app launch offline, and it's a prerequisite for push, background sync and the rest of Background & Engagement. What you shouldn't ship is an empty fetch handler. It gives the browser nothing and makes it start your worker for every navigation. If you don't handle fetch, leave the listener out.

Verdict: outdated since 2023.

Myth 4: "A service worker always makes your site faster"¶

The claim. Add a service worker and your site gets faster, because everything comes from the cache.

The evidence. A worker makes cached responses fast. It makes everything else slower by the time it takes to start the worker, because the browser can't send a request to the network until the worker's fetch handler has decided what to do with it. Google's write-up of bringing service workers to Google Search puts it directly: "The amount of time that it takes to start up and run the service worker code is pure overhead added on top of every navigation." Google Search only registered its worker in browsers with navigation preload, on devices with at least 2 GB of RAM and enough free storage. It reported that repeat visits handled by the worker downloaded "half as much new JavaScript", which "directly leads to 6% fewer delayed user interactions".

Two platform features exist to remove the overhead:

• Navigation preload starts the network request for a navigation while the worker boots. It's in all three engines (Chrome 59, Firefox 99, Safari 15.4 according to MDN).
• The Static Routing API lets the worker declare, at install time, which requests should skip it entirely. Chrome shipped it in 123 and Safari in 27; Firefox doesn't support it yet.

self.addEventListener("install", (event) => {
  // Requests that match these rules never wake the worker (Chrome 123+, Safari 27+).
  if (event.addRoutes) {
    event.waitUntil(
      event.addRoutes([
        // A string pattern is resolved against the worker script's URL.
        { condition: { urlPattern: "/api/*" }, source: "network" },
        { condition: { requestMode: "navigate" }, source: "race-network-and-fetch-handler" },
      ]).catch((error) => {
        // A rejected addRoutes() inside waitUntil() would fail the whole install.
        console.warn("Static routes rejected:", error);
      }),
    );
  }
});

self.addEventListener("activate", (event) => {
  // For browsers without static routing: overlap worker startup with the request.
  // Your fetch handler must then use event.preloadResponse for navigations.
  event.waitUntil(self.registration.navigationPreload?.enable() ?? Promise.resolve());
});

Navigation Preload and Static Routing API explain both in depth. To know whether your worker helps, compare pages that it controlled with pages it didn't in your field data, not before and after in a lab. Measuring Performance shows how.

Verdict: false. A worker is a tool for making some responses faster. Used carelessly, it slows down all the others.

Myth 5: "A PWA must work fully offline"¶

The claim. If it doesn't work on a plane, it isn't a real PWA.

The evidence. No specification defines a PWA, let alone an offline requirement. Chromium stopped requiring offline support for installation in 2023. What users need is for the app to fail well: never the browser's error page, always a clear state. Offline support is a spectrum, and each level costs more than the previous one:

Level 4 is also where the browsers differ most. The Background Sync API, which retries a queued request after connectivity returns, even if the page was closed, is Chromium-only. Everywhere else you retry when the app next runs:

// Flush queued writes: via Background Sync where available, otherwise when the
// page is open and the network is back. flushOutbox() must be idempotent.
let pageTriggersInstalled = false;

export async function scheduleOutboxFlush(flushOutbox) {
  // getRegistration() resolves to undefined when there is no worker;
  // navigator.serviceWorker.ready would never settle in that case.
  const registration = await navigator.serviceWorker?.getRegistration();
  if (registration?.active && "sync" in registration) {
    try {
      await registration.sync.register("outbox"); // Chromium: the worker gets a "sync" event
      return;
    } catch {
      // Permission or policy refused it: fall through to the page-driven path.
    }
  }

  // Everywhere else: retry while the app runs. Install the triggers only once,
  // however often a write schedules a flush.
  if (!pageTriggersInstalled) {
    pageTriggersInstalled = true;
    const tryFlush = () => {
      if (navigator.onLine) flushOutbox().catch((error) => console.warn("Outbox flush failed:", error));
    };
    window.addEventListener("online", tryFlush);
    document.addEventListener("visibilitychange", () => {
      if (document.visibilityState === "visible") tryFlush();
    });
  }
  if (navigator.onLine) await flushOutbox();
}

Offline UX & Fallbacks covers levels 1 to 3, and Offline-First Data & Sync covers level 4.

Verdict: false. Choose the level your users need. For most apps it's 1 or 2, and a Level 1 fallback takes an afternoon.

Myth 6: "PWAs have to be single-page apps"¶

The claim. A PWA needs an app shell and client-side routing, so a server-rendered multi-page site can't be one.

The evidence. Nothing in the manifest or service worker specifications refers to an architecture. A service worker intercepts navigations as well as subresource requests, so it can cache, prefetch and serve whole server-rendered pages. It can also stream responses built from cached headers and fresh content. Multi-page apps have caught up on the one thing SPAs used to do better, smooth transitions: cross-document view transitions (@view-transition { navigation: auto; }) animate between full page loads in Chrome 126 and later and Safari 18.2 and later, according to MDN. Firefox doesn't support them yet. View Transitions covers the details and current support.

Multi-page PWAs also avoid some SPA problems. Every navigation is an update check for the worker, so a new version is found and installed promptly (it still waits to activate until no page uses the old one, or until you call skipWaiting()). Every URL is a real document for crawlers. And there's no client-side router to integrate with an update flow. Published case studies include multi-page PWAs, such as Ele.me, which kept separate pages for its business units. See Case Studies.

Verdict: false. Choose the architecture for your content and team, then add the PWA layers. SPA vs MPA PWAs compares the trade-offs.

Myth 7: "Storage is 5 MB, and Safari wipes it every seven days"¶

The claim. Browsers give you 5 MB, and Safari deletes everything after a week anyway, so offline data isn't practical.

The evidence. The 5 MB figure is real, but it's about localStorage, which is synchronous, string-only and shouldn't hold app data. The storage PWAs use (Cache Storage, IndexedDB and the Origin Private File System) shares a per-origin quota that is a fraction of the disk:

On a phone with 128 GB of storage, that's gigabytes, not megabytes. Measure what you actually get with navigator.storage.estimate(), which works in windows and workers in all three engines.

The seven-day rule is also real, but narrower than the myth. WebKit's Intelligent Tracking Prevention deletes script-writable storage for a site after seven days of Safari use in which the user hasn't interacted with the site. Days the user doesn't open Safari don't count. Home Screen web apps have their own counter of days of use, separate from Safari's, so an installed app used regularly isn't affected. On top of that, WebKit grants persistent storage "based on heuristics like whether the website is opened as a Home Screen Web App".

// Ask for persistence at a meaningful moment (after install, or when the user
// saves something for offline use), then report what the browser granted.
export async function ensureDurableStorage() {
  if (!navigator.storage?.persist) return { persisted: false, supported: false };
  const persisted = (await navigator.storage.persisted()) || (await navigator.storage.persist());
  const { usage = 0, quota = 0 } = await navigator.storage.estimate();
  return {
    supported: true,
    persisted, // true: the browser won't evict this origin without asking the user
    usageMB: Math.round(usage / 1e6),
    quotaMB: Math.round(quota / 1e6),
  };
}

Browsers do evict best-effort data under storage pressure, least recently used origins first, and no event tells you when it happens. Design for re-download: treat caches as caches, and keep anything the user created in persistent storage or synced to your server.

Verdict: mostly false. Quotas are generous, and the seven-day cap mostly affects sites people don't come back to. Storage Quotas & Persistence has the per-browser rules.

Myth 8: "Updating an installed PWA needs a store release"¶

The claim. Once users install your PWA, you're stuck shipping updates the way native apps do, or worse, users keep the old version forever.

The evidence. Two separate update mechanisms keep an installed PWA current, and neither involves a store:

1. The service worker and your assets update whenever the browser finds a new worker script. It checks on navigations into scope, after functional events when the registration is more than 24 hours stale, and whenever you call registration.update(). With the default updateViaCache: "imports" (supported since Chrome 68, Firefox 57 and Safari 11.1 according to MDN), those checks bypass the HTTP cache for the main worker script.
2. The manifest (name, icons, colors, shortcuts and so on) is re-read by the browser. Since Chrome 144 on desktop, Chrome checks every time a page that links the manifest loads, without the previous once-a-day limit. It applies most fields silently, and offers name and icon changes as an optional Review app update item in the app menu. Icons count as changed only when their manifest entries change, so publish new icons under new URLs. On Android, Chrome regenerates the WebAPK in the background, at most about once a day. Safari and Firefox document no mechanism that applies later manifest changes to an app that's already installed, so treat what they read at install time as fixed.

Even a PWA packaged for Google Play as a Trusted Web Activity loads its content from your server, so content changes don't need a new store upload. Only changes to the Android package itself (the launcher, Digital Asset Links configuration, target SDK) do.

The real problem is the opposite of the myth: an installed app updates too quietly. A new service worker waits until every window of the app is closed, and installed apps often stay open for days. You decide how updates reach open windows. Service Worker Update Patterns Compared compares five ways to do it, and App Identity & Updates covers manifest updates.

Verdict: false.

Myth 9: "PWAs can't be published in app stores"¶

The claim. If you want to be in the app stores, you have to build a native app.

The evidence. Most of the big stores accept PWAs in some packaged form:

• Google Play accepts an Android app bundle that opens your site in a Trusted Web Activity. Google's Bubblewrap CLI and PWABuilder generate the project, and a /.well-known/assetlinks.json file proves you own the site.
• The Microsoft Store accepts PWAs packaged as MSIX, which PWABuilder generates from your manifest. Microsoft documents the process in Publish a PWA to the Microsoft Store.
• The Samsung Galaxy Store and the Meta Horizon Store accept Android packages, including TWA-based ones.
• Apple's App Store is the exception. There's no PWA submission path, so you ship a native app that hosts your site in a WKWebView. It has to pass App Review on its own merits: guideline 4.2 asks for "features, content, and UI that elevate it beyond a repackaged website".

Store policies follow your web content into the package. If you sell digital goods, Google Play's payments policy applies to your TWA, and your web code has to use Play Billing through the Digital Goods API. Publishing to App Stores walks through each store, and PWABuilder covers the packaging tool.

Verdict: false, with an asterisk for Apple.

Myth 10: "PWAs can't access hardware or the file system"¶

The claim. Web apps are sandboxed away from the device, so anything involving Bluetooth, USB, serial ports or real files needs a native app.

The evidence. Most of these APIs exist and have shipped in stable browsers for years, but mostly in Chromium. From MDN's browser compatibility data (September 2026):

Support data as of September 2026. ⚠️ MDN marks desktop Web Bluetooth as partial because it isn't enabled by default on Linux (before Chrome 70 it was macOS-only). ⚠️ Firefox's Web Serial requires the user to install a site-permission add-on for the site. Check MDN and caniuse for live data.

Mozilla and Apple have published negative standards positions on several of these APIs, citing security and privacy concerns, including fingerprinting and the difficulty of explaining device access in a permission prompt. So the accurate claim is narrower than either side of the argument: a Chromium-based PWA can talk to many classes of hardware, and a cross-browser PWA mostly can't. Design with feature detection so the same app works everywhere, with the device features as an enhancement:

// Offer the richest connection the browser supports, and say so honestly when none.
export function availableTransports() {
  return {
    serial: "serial" in navigator,     // Chromium desktop, Chrome Android 148+, Firefox 151+ desktop
    usb: "usb" in navigator,           // Chromium
    bluetooth: "bluetooth" in navigator && typeof navigator.bluetooth?.requestDevice === "function",
    hid: "hid" in navigator,           // Chromium desktop
  };
}

Hardware & Device APIs and File System Access cover each API. For the highest-trust APIs, such as raw TCP and UDP sockets, Chromium's answer is Isolated Web Apps, which are signed, packaged and so far limited to managed ChromeOS devices.

Verdict: half true. "PWAs can't" is wrong. "PWAs can, everywhere" is also wrong.

Myth 11: "PWAs rank better (or worse) in search"¶

The claim. Google rewards PWAs, or the opposite, JavaScript-heavy PWAs can't be indexed.

The evidence. Google documents no ranking signal tied to a manifest, a service worker or installability, and its page experience documentation doesn't mention them. Search sees your pages the way a first-time visitor does. Google's JavaScript troubleshooting guide says the renderer "does not retain state across page loads", clears local storage, session storage and cookies between loads, and that you should "expect Googlebot to decline user permission requests". A service worker installed on one page load doesn't help the next, so your worker is effectively invisible to indexing.

That cuts both ways:

• No bonus. Installability and offline support don't affect ranking.
• No penalty either, as long as the server returns meaningful HTML for each URL, or client-side rendering produces it without waiting for the worker, a permission or stored state.

Being a PWA helps search indirectly, through what it does for users: faster repeat visits and better Core Web Vitals in the field. The failure mode to avoid is an app shell that renders nothing until JavaScript fetches data, with only the worker able to build the page. SEO for PWAs covers rendering strategies, URLs and the other details.

Verdict: false in both directions.

Myth 12: "Installing a PWA gives it more power over the device"¶

The claim. Either "installing a web app is dangerous, because it gets native-app permissions", or "install it and it can do everything a native app can".

The evidence. Installing doesn't grant any permission. An installed app asks for camera, location, notifications and the rest through the same permission prompts as a tab. Permissions covers how each browser handles them. It also runs in the same sandbox, with the same origin, and in Chromium the same storage as the site in a browser tab.

What installation does change is which capabilities are available at all. Some features only make sense for, or are only offered to, installed apps:

So the security worry is mostly unfounded, and the capability claim is conditional. Installation unlocks integration with the operating system, not access to anything a user hasn't granted.

Verdict: half true. Installing doesn't grant permissions, but it does unlock some capabilities.

How to check a PWA claim yourself¶

Most of these myths survived because nobody rechecked a claim that was once correct. When you meet the next one:

1. Check the date. A blog post from 2019 about iOS is a history lesson. Web platform support changes with each x.0 and x.4 Safari release and every Chrome milestone.
2. Check MDN's compatibility data for the exact API, not a summary. The data behind MDN's tables is also published as the @mdn/browser-compat-data package, which you can query in CI.
3. Check Chrome Platform Status and the standards positions of Mozilla and WebKit for anything experimental. A shipped Chromium feature with an "oppose" position from WebKit won't reach iOS soon.
4. Test it. Most claims in this post can be checked in ten minutes with DevTools or a Playwright script, as Auditing PWAs After Lighthouse Dropped the PWA Category shows.

Further reading¶

On this site

• What Is a PWA?
• PWA vs Native vs Hybrid
• Installability Criteria
• iOS & iPadOS
• Storage Quotas & Persistence
• Publishing to App Stores
• When to Build a PWA
• FAQ

External references

• Revisiting Chrome's installability criteria, Chrome for Developers
• WebKit Features in Safari 26.0, WebKit blog
• Web Push for Web Apps on iOS and iPadOS, WebKit blog
• Updates to Storage Policy, WebKit blog
• Full Third-Party Cookie Blocking and More, WebKit blog (the seven-day cap)
• Bringing service workers to Google Search, web.dev
• Storage quotas and eviction criteria, MDN
• App Review Guidelines, Apple