Consent in Progressive Web Apps: When the Site Works Offline and the Banner Logic Does Not
Progressive web apps break the assumptions consent tooling was built on. A normal website loads fresh, shows its banner, and reads the current configuration. A PWA installs a cached shell, works offline, wakes in the background to sync, registers for push, and updates itself silently when a new service worker activates. Every one of those behaviors has a consent consequence, and almost none of them appear in a standard banner audit, because the audit happens in a browser tab on first load.
Teams adopt PWAs for engagement and then discover the consent layer was designed for documents, not applications. This guide covers where PWA mechanics collide with consent: cached shells, background sync, push registration, and updates, and what a consent design that survives them looks like.
The cached shell keeps old promises
When a visitor installs or revisits a PWA, the service worker may serve a shell cached weeks ago, complete with the tag configuration and vendor list from that version. Meanwhile the consent banner's categories, and the privacy notice behind them, have moved on. The visitor is being tracked under a description of processing that has since been edited, which is the definition of stale consent. Version the consent configuration with the app: when the shell or the tracking inventory changes materially, the stored choice should be flagged for renewal on next launch. If your release process can force a terms update on users, it can force a consent refresh; the machinery is the same and the trigger list overlaps.
Background sync does not know about the banner
Background sync and periodic fetch are designed to run when no page is open, which means no banner, no visible state, and no opportunity to ask. Anything synced in the background, analytics batches, behavior logs, offline actions, was collected under a consent state the code must have checked before registering the sync, not during it. Audit the registration points: which code paths enroll the device in sync or push, and do they read the stored consent first? Push registration deserves special care, because subscribing an identified device to notifications is processing with a marketing flavor in most taxonomies, and it commonly happens in an onboarding flow that treats it as a pure feature.
Offline collection and the delayed upload
Offline first design queues events locally and uploads them when connectivity returns, possibly days later and possibly after the visitor has withdrawn consent in the meantime. The withdrawal has to reach the queue. A well built app checks consent at upload time as well as collection time and purges queued data in withdrawn categories; a typical one ships whatever accumulated. Test this deliberately: go offline, use the app, withdraw consent, reconnect, and watch what leaves the device. The result is often the finding that reorders the roadmap, because it shows consent as a runtime system rather than a banner, and it gives the team a concrete, fixable defect instead of an abstract worry.
Designing consent as app state
The durable pattern treats consent like the other durable app state. Store it in the same persistent store as the user profile, expose it through one internal API that every tracking, sync, and push call must consult, and log changes with timestamps that survive reinstalls where the platform allows. Surface the settings inside the app's own settings screen, not only on a website the installed user may never open. And include consent state in crash and QA telemetry checklists: if a build can ship with the paywall disabled by accident, it can ship with the consent check bypassed the same way. The banner is the visible tip; in a PWA, the system underneath is the product.
Related reading
These earlier guides cover connected questions in more depth: Prefetch, Preconnect, and Consent: Network Hints That Leak Before a Choice, How Consent Records Hold Up in a Regulatory Audit, and Returning Visitors and Consent Expiry: When to Ask Again.
Frequently asked questions
Does installing a PWA count as consent to tracking?
No. Installing, adding to the home screen, or enabling the app to work offline is a functional choice about the software, not agreement to analytics, advertising, or profiling. Those still need their own categories and choices, presented in the app's context.
What happens to stored consent when the app updates?
It persists, which is the problem when the update changes what the app tracks. Material changes to the tracking inventory or purposes should trigger a consent renewal prompt at next launch. Silent updates make silent consent expansion easy, and that ease is the risk.
Can a PWA collect analytics offline under a refusal?
It should not collect them at all under a refusal, and the queue design decides whether intentions survive contact with the code. Check collection, storage, and upload as three separate gates. Many apps gate the upload and leave collection running, which still creates a store of data the visitor refused to provide.
Where should PWA consent settings live?
In two places that stay in sync: the first run banner for the initial choice, and the app's settings screen for changes afterward. Installed app users may never return to the browser version, so a settings link that only exists on the website abandons exactly the users with the deepest data relationship.