Re: [w3c/ServiceWorker] Allow the service worker to work in the background without stopping for installed PWA (Issue #1728)

yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1728)

Your passion for enhancing PWA capabilities is appreciated. I agree that when a user "installs" a PWA, they expect a more integrated, app-like experience. However, I believe granting persistent background execution similar to native apps presents some fundamental challenges, not just for the spec but for the user experience across different platforms.

While this is partly a browser/OS-specific implementation detail rather than a spec-only issue, the current landscape highlights some difficulties:

1. **Inconsistent Management and Monitoring**: As you've noted, the methods for viewing installed PWAs and, more importantly, monitoring their resource usage are not consistent. On Android, a PWA is treated much like a native app, and its battery usage can be inspected in the system settings. This allows for the user self-regulation you described. However, on iOS and desktop operating systems, a PWA's resource consumption is often bundled with the browser's overall usage, making it difficult for a typical user to identify and manage a misbehaving PWA. Without a consistent, user-friendly way to monitor resources, granting persistent background access carries a higher risk on these platforms.

2. **"Installed" Does Not Mean "Unkillable"**: A crucial point is that even native installed applications are not guaranteed to run forever in the background. For example, Android will terminate app processes to reclaim memory based on an "importance hierarchy" ([ Processes and app lifecycle](https://developer.android.com/guide/components/activities/process-lifecycle)). Furthermore, since Android 8.0, "Background Execution Limits" have been in place to prevent idle apps from consuming resources unchecked ([ Background Execution Limits](https://developer.android.com/about/versions/oreo/background)). Therefore, giving PWAs a level of persistence that even native apps don't truly have seems like a step too far.

Instead of allowing indefinite background execution, perhaps we could explore a middle ground. If a Service Worker needs to run in the background, it is usually to complete a specific, long-running task (like a file upload, data sync, etc.).

A more viable path might be to require Service Workers to declare and report progress on such tasks. For example, a proposal like the (now dormant) [Progress Notification API](https://github.com/explainers-by-googlers/progress-notification) aimed to make these tasks transparent to the user. An API in that spirit could be a prerequisite for extended background time. This would provide a clear signal to both the user and the browser about what the PWA is doing. The browser could then use this information to manage the Service Worker's lifetime, potentially terminating it if the task stalls or runs for an unreasonable amount of time.

However, I still lean on sticking current background capabilities to ServiceWorkers. (i.e. even if PWA, its lifetime is quite limited).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1728#issuecomment-3389055643
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1728/3389055643@github.com>