A PWA Audit Found 61% Failed Offline. That’s a Trust Problem

An app icon makes a promise. It says the product is close at hand, belongs on the device and will be ready when the user taps it. For a surprising number of installable web apps, that promise ends as soon as the network does.

PWA Directory says it opened 386 installable web apps with the network disconnected on August 12. Only 151 kept working; 235 did not. In percentage terms, roughly 39% remained usable and 61% failed the offline test.

This is not proof that 61% of all progressive web apps fail offline. It is a snapshot of one curated directory, and the published page does not provide enough detail about devices, browsers, app categories or repeat runs to treat it as an ecosystem-wide benchmark. But the result is still too large and too relevant to dismiss. It exposes a product problem that PWA teams have allowed technical terminology to hide: installability and reliability are different achievements.

What the audit actually found

The directory describes a direct, human-run test: load an app, cut the network and see whether it still works. Every app in the tested group was considered installable by the directory, but fewer than four in ten remained useful after connectivity disappeared.

That simple test matters because it follows the user journey rather than inspecting a checklist. A valid manifest can supply a name, icon, launch URL and app-like display mode. Installation can place the product on a home screen, taskbar or app launcher. Neither result proves that the interface, content or user data will be available without the server.

The audit page also describes several degrees of offline behavior. An app may show only its visual shell, preserve previously loaded content, or support local changes that synchronize later. Those experiences are not equivalent. A cached header surrounding an endless spinner technically renders, but it does not help someone retrieve a boarding pass, review field notes or tick an item off a shopping list.

The browser is not certifying product quality

Part of the confusion comes from years of treating browser installability criteria as a PWA quality standard. They are not. Installation is primarily a packaging and presentation capability: the browser determines whether it can create a coherent installed experience and whether the user has chosen to do so.

Modern Chromium installation does not generally require a service worker merely to let a user install a site from the browser menu. That makes the audit’s central distinction even more important. A service worker remains the main tool for custom offline navigation and caching, but its existence alone would not prove that useful resources or data have been stored.

Other platforms make the separation equally visible. A website may be added to an operating-system launch surface and open in an app-like window without offering meaningful offline functionality. The icon communicates presence. The application architecture determines resilience.

For users, that distinction is mostly invisible. They do not think in terms of manifests, cache strategies or IndexedDB. They see an installed app and bring expectations formed by native software: predictable launch behavior, a comprehensible failure state and access to at least some recent information when connectivity is poor.

Why founders and product teams should care

Offline capability is often filed as an engineering enhancement for travel or remote work. The larger issue is trust. Mobile networks fail in elevators, trains, warehouses, conference halls and crowded city centers. Connections can also be present but too unstable for an API-dependent interface to become usable.

When an ordinary webpage fails, users blame the connection. When an installed app opens to a blank screen, they are more likely to blame the product. Installation raises expectations because it changes the product’s position on the device.

That has consequences beyond one interrupted session:

• Activation: A user who installs but encounters a failed launch may never establish a habit.
• Retention: A home-screen icon has little value if the app is unreliable in the moments when quick access matters most.
• Support: Intermittent connectivity produces reports that are difficult to reproduce on a developer’s fast connection.
• Brand trust: A blank standalone window feels broken, even if the underlying website works again moments later.
• Distribution: Store-free installation is less persuasive when the installed experience lacks a clear reliability contract.

Investors and partners should care for the same reason. Installation totals alone do not establish app quality or durable engagement. The useful questions are what happens after launch, how much of the product survives degraded connectivity and whether offline failures correlate with abandonment.

Offline should be a product tier, not a checkbox

Not every web app needs full local-first operation. A live trading interface, multiplayer game or cloud-rendering tool may be unable to deliver its core value without a server. Pretending otherwise would create new safety and consistency problems.

Every installed web app can still define an honest minimum. That may be a designed offline screen explaining what is unavailable. It may include recent read-only data, queued form submissions or a complete local workspace with later synchronization. The right level depends on the product, but it should be chosen deliberately.

A useful three-tier model is:

• Graceful failure: The app launches reliably, preserves its structure and explains the connection problem without a blank screen.
• Offline reading: Previously accessed content and essential reference data remain available.
• Offline work: Users can create or change data locally, with visible synchronization and conflict handling after reconnection.

Teams should describe the tier precisely. If only the shell works, do not market the app as available offline. If cached content works but editing does not, say so in the interface. Reliability claims are product promises, not implementation trivia.

The test plan builders need now

The audit’s biggest contribution may be its blunt test method. Disconnecting the network and opening the app reveals more than a manifest audit ever could. Production teams should turn that moment into a repeatable release gate.

• Test a first visit, an installation followed by one online launch, and a well-used app with populated local data.
• Launch while fully offline and while the connection is slow, intermittent or returning errors.
• Verify that critical navigation requests have a controlled fallback.
• Check whether authenticated screens fail safely when tokens expire offline.
• Test service-worker updates so an old shell and new data schema cannot strand the user.
• Exercise offline writes, duplicate submissions, synchronization order and conflicts on multiple devices.

Instrumentation should distinguish an offline launch from an ordinary crash or abandonment. Teams cannot improve a reliability path they cannot observe. Privacy-respecting telemetry can record whether the app reached a usable state, served a fallback or recovered after reconnection without capturing the user’s content.

What changes for installable web apps

No new browser API arrived with this audit. What changes is the quality bar. Installability should be treated as the start of the installed experience, not its finish line. A manifest and polished icon earn placement on the device; resilient launch behavior earns the right to stay there.

That shift is commercially important for the open web. PWAs compete on reach, direct distribution, instant updates and a single codebase across platforms. Reliability is what turns those structural advantages into a credible app proposition. If users cannot predict what the icon will do, distribution freedom alone will not create loyalty.

What IndApp watches next

IndApp will watch for broader, reproducible measurements that separate app categories, browsers and degrees of offline usefulness. A public test corpus and versioned results would make it possible to see whether the 61% failure rate is improving rather than relying on one directory snapshot.

We are also watching for better browser and directory signals. An install prompt should not become a vague quality certification, but users could benefit from clear, verifiable information about whether an app offers an offline fallback, cached reading or offline editing.

The immediate move belongs to builders: install the production app, disconnect the network and tap its icon. If the result would embarrass the team in a customer demo, the app is not finished merely because the browser agreed to install it.