A service worker does not make an entire product safely offline. Offline behavior is a product contract for each screen and action: what can be viewed, drafted, committed, retried, reconciled, or blocked when the network is weak or absent. Without that contract, the interface can claim success while the server never received the work.
Create a PWA offline scope matrix before implementation. Put user tasks in rows and online, weak, offline, and recovered states in columns. For each cell, specify data source, freshness, local persistence, user message, conflict rule, retry rule, and acceptance test. This makes trade-offs visible to product, design, engineering, security, and operations.
Separate view, draft, and commit
A read-only screen may display a recent cached snapshot. A draft form may safely store local input. A commit such as payment, stock adjustment, access approval, or account change may need the server and should remain blocked. Do not label all three “offline capable.”
Define an action mode for every task: unavailable, cached view, local draft, queued command, or fully local operation. Explain the mode in the UI before the user acts, not only after a request fails.
Define freshness and provenance
Cached data needs a timestamp and source. Decide how old a schedule, price, membership state, or stock value may be before it becomes misleading. Display a stale warning and a refresh path. Sensitive decisions may require a shorter validity window or no offline view.
Keep server data and local drafts distinguishable. A user should know whether they are reading the last synchronized record or an unsent edit. Do not overwrite newer server state merely because a device reconnects later.
Choose what remains blocked
List actions that create irreversible financial, legal, security, or inventory effects. Payments, refunds, permission changes, destructive deletes, and externally issued invoices often require an online confirmation. Blocking them honestly is safer than simulating completion.
Offer a useful alternative where possible: save a draft, capture a reference, or show contact instructions. The UI should state that the operation is not complete and avoid a success color or receipt until the server confirms it.
Design queued commands carefully
A queued command needs a stable client identifier, authenticated ownership, serialized input, expiry, and replay-safe server handling. Show pending, syncing, succeeded, needs review, or failed states. Let users inspect and retry appropriate failures without creating a second command.
Do not queue secrets or unlimited personal data. Encrypt local storage where the platform permits, minimize retained fields, and clear completed or expired entries. Consider what another person could see if the device is shared or lost.
Resolve conflicts by domain rule
“Last write wins” is not a universal conflict strategy. A note draft may merge or ask the user, while a stock movement, booking slot, or membership decision requires server validation. Define the authoritative fields and the action when both device and server changed.
Present the conflict in task language. Show what changed and who or what source owns the current value. Avoid raw JSON or silently discarding work. Record the resolution so support can explain the final state.
Handle files separately
Photos and documents are larger, slower, and more sensitive than form fields. Store a local reference and upload state, enforce file type and size, and preserve the link to the pending command. A form must not claim completion while required evidence is still on the device.
Test app closure, device restart, partial upload, duplicate selection, and a file removed by the operating system. Provide cancellation and cleanup so abandoned media does not consume storage indefinitely.
Design recovery after reconnection
Reconnection may oscillate. Use backoff, network-aware retries, and server idempotency rather than sending the full queue at every event. Order commands when one depends on another, and stop a dependent item when its prerequisite fails.
Show a concise summary after recovery: how many succeeded, what needs review, and what remains pending. Do not interrupt the user with a success toast for every background item. Keep a durable history long enough for support and then apply retention.
Protect authentication and sessions
Decide what happens when a session expires offline. A local draft may remain encrypted for later re-authentication, but protected data should not become available merely because a previous session existed. Do not store long-lived credentials inside the queue.
Test account removal, role changes, tenant changes, and remote logout before synchronization. The server must re-authorize every command at processing time. A command captured while allowed may no longer be allowed later.
Instrument the offline funnel
Measure network state, queued count, age, failure category, conflict count, and recovery duration without collecting form contents. Alert on queues that never drain or a release that increases rejected commands. Provide support with identifiers, not sensitive payloads.
Use real device and network testing. Browser simulation is useful but does not cover operating-system eviction, background restrictions, storage pressure, or device-specific service worker behavior. Include supported mobile browsers in acceptance.
Build the matrix screen by screen
For a booking screen, define cached availability, offline draft, and online final reservation. For field service, define downloaded assignments, local evidence, and validated completion. For a dashboard, define snapshot freshness and disabled filters that need the server.
Start with three critical screens and prove recovery before expanding. A small reliable offline scope is more useful than a site-wide service worker that caches assets but leaves business actions ambiguous.
Discuss a PWA scope and implementation, review the web application stack, and compare the existing offline-first architecture guide. Bring a three-screen matrix rather than a request to “make everything offline.”
Conclusion: make every offline promise testable
The offline scope matrix converts a vague feature into explicit modes, freshness, storage, conflicts, retries, security, and recovery. It also gives design honest language for pending work. Implement the smallest valuable matrix, test it on real devices, and expand only when users and operations can explain every state.
