Repository navigation
Allow the service worker to work in the background without stopping for installed PWA #1728
Description
Current situation:
as soon as the page is closed or becomes inactive, the browser stops the work of the service worker. The idea is clear - the browser cannot keep all service workers of all pages ever opened in working state.
But not so long ago, we had the opportunity to install PWA applications (or add them to the home screen in iOS)!
This action transfers a simple page with service worker to the category of installed applications.
Native installed applications have the privilege to stay running in the background.
Why do the installed PWA applications not have this feature!?
Proposal:
to allow the installed PWA applications to have service worker running in the background without stopping until they are uninstalled.
Activity
mxk700 commentedon Sep 4, 2024
This looks like a nice improvement for user experience, I'd like to have this feature for PWA service workers.
AlekseyMelikov commentedon Jul 27, 2025
The feature is useful and necessary
yoshisatoyanagisawa commentedon Jul 28, 2025
I understand the desire for PWA background capabilities closer to native apps. However, allowing persistent Service Worker execution poses significant security and privacy risks due to fundamental differences in how PWAs and native apps operate.
Why it's Different for PWAs:
User Expectations & Control: Users expect web activity to end when a tab closes. Unlike native apps with clear OS-level permissions and controls, a continuously running Service Worker would violate this expectation, making it hard for users to know or control what's happening in the background, risking covert data collection.
Ease of Abuse: Native apps go through app store vetting. PWAs, like any website, are easily distributed without such reviews. Granting persistent background access could turn this ease into a vulnerability, making it simple for malicious PWAs to form botnets, persistently steal data, or excessively drain resources without immediate detection or control.
Browser's Role: The browser manages resources for all web content. Unrestricted background PWAs would overwhelm this management, jeopardizing overall web performance and stability. Native apps rely on the OS for this governance, a level of control the browser doesn't have over web content.
In essence, while more background capabilities are appealing, persistent Service Workers introduce disproportionately higher risks to user security, privacy, and device performance within the current web model. The existing event-driven Service Worker design is a crucial balance to mitigate these dangers.
budarin commentedon Oct 3, 2025
I have some objections.
as a user and a developer, I don't understand why, if I INSTALLED a PWA application (and not just opened the site in a browser), why do I expect the application to behave like a page and not like a native application??
where will uncontrolled background PWAs come from? The user INSTALLS a maximum of 3-5 applications!
a simple analysis of the application discharge will show which application is abusing resources and I, as a user, will immediately delete it and so everyone does!
yoshisatoyanagisawa commentedon Oct 10, 2025
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:
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.
"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). Furthermore, since Android 8.0, "Background Execution Limits" have been in place to prevent idle apps from consuming resources unchecked ( Background Execution Limits). 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 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).
budarin commentedon Oct 10, 2025
I agree with your theses in the second half of the previous post: we need to at least consider changes to the protocols and regulations for background processes in PWA applications and especially installed ones.
The current situation with calling background synchronization once a day simply kills the functionality of many applications for which such an update frequency is equivalent to its absence and puts the PWA application in a losing position in comparison with native ones.
I am glad that at least there is a discussion of this issue, which has not been reviewed at all for many years.
jimmywarting commentedon Feb 5, 2026
I think that at least Mac user could get extra privileges to be able to run SharedWorker when a PWA is installed and all windows are closed.
It's very common for Mac user to know that closing a windows dose not always equal to shutting down the process
Apple was thinking: it should always be ready and doing work in the background rather than shutting down everything.
Service worker have a very strict limited life cycle and gets killed every now and then...
And i would not like to relay on that to build Apps that should be able to run in the background.
it would be nice if we could create SharedWorker where the lifetime of a SharedWorker stays alive until the app is terminated (Cmd+Q). And not terminated when simply closing the window (Cmd+W)
I can't say the same holds true for windows users where the expectation are more like: closing all window terminates the hole process