Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use Angular’s SwUpdate service to handle application-version updates and SwPush for Web Push messages and notification interactions. For most updates, listen for a ready version, ask the user before refreshing, and reload the page; use no-reload activation only when you have verified that the running app can safely mix versions.
Choose the Angular service for the communication you need
Angular provides higher-level services so an application usually does not need to communicate with its service worker through low-level browser messaging. The main distinction is the task:
SwUpdatereports application-version events and supports update checks, activation, and recovery from an unrecoverable client state.SwPushexposes Web Push subscriptions, incoming messages, and notification interactions. Push is separate from the application update lifecycle.
Angular describes its service worker as “a basic caching utility for simple offline support with a limited featureset” and recommends exploring native browser APIs for more advanced caching and offline capabilities. That recommendation concerns advanced caching needs; it does not replace SwUpdate for Angular’s documented update lifecycle. Angular’s service-worker overview
Listen for application update events with SwUpdate
Inject SwUpdate and subscribe to its versionUpdates observable. Check the event’s type to decide what the application should do. Angular documents four event types:
#1 Best Overall
VERSION_DETECTED: Angular has detected a new version.NO_NEW_VERSION_DETECTED: the check did not find a newer version.VERSION_READY: the new version has been downloaded and is ready for the client to use.VERSION_INSTALLATION_FAILED: installation of the detected version failed.
A typical flow is to notify the user when VERSION_READY arrives, explain that refreshing will load the new version, and reload only after the user agrees. Installation failures can be logged or sent to the application’s monitoring system. The observable is an Observable<VersionEvent>; the related unrecoverable observable reports a client state that cannot be repaired through the normal update process. Angular’s communication guide and the SwUpdate API reference
Use manual checks when the default checks are not enough
Angular checks for updates during service-worker initialization and on navigation requests. If the application needs an additional scheduled or user-triggered check, call checkForUpdate(). Its promise resolves to true when a new version is found and ready, false when no update is found, and rejects if the check fails. Handle the rejection rather than assuming every browser or connection can complete the check.
Rank #2
Scheduled checks can make sense for an application that changes frequently or needs to check at a particular time. Angular’s example waits for the application to become stable, then starts a six-hour RxJS interval. Six hours is an example cadence, not a universal recommendation; choose an interval appropriate to the application.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →import { ApplicationRef, inject } from '@angular/core';
import { SwUpdate } from '@angular/service-worker';
import { filter, first, interval } from 'rxjs';
const appRef = inject(ApplicationRef);
const updates = inject(SwUpdate);
appRef.isStable.pipe(
first((stable) => stable),
).subscribe(() => {
interval(6 * 60 * 60 * 1000).subscribe(() => {
updates.checkForUpdate().catch((error) => {
console.error('Update check failed', error);
});
});
});
The key timing issue is stabilization: Angular’s default registration strategy waits up to 30 seconds for the application to stabilize before registering the worker. Starting a recurring task too early can keep the app from becoming stable and delay registration. Wait for ApplicationRef.isStable before starting polling, or configure an appropriate registration strategy. Angular’s communication guide
Rank #3
Prefer a user-approved reload over no-reload activation
Once VERSION_READY arrives, the usual safe approach is to tell the user an update is ready and reload after consent. This replaces the running application shell and its resources together, while avoiding an unexpected interruption in the middle of work.
activateUpdate() can activate the new version in the current client without reloading. That can leave the tab running a new shell alongside resources from an older version—for example, lazy-loaded chunks expected by the old shell. If those versions are incompatible, the application can break. Angular’s API reference says: “In most cases, you should not use this method and instead should update a client by reloading the page.” Use no-reload activation only after validating the application’s version-compatibility behavior. Angular’s SwUpdate API reference
Rank #4
Recover from an unrecoverable client state
Subscribe to SwUpdate.unrecoverable and offer a clear recovery action, normally a full-page reload. This event indicates that the current client cannot recover its expected assets. One documented scenario is an old application shell whose cached lazy-loaded chunk has been evicted by the browser, while the server now retains only the new hash-named chunk. The old shell cannot retrieve the exact asset it expects, so a reload is needed to load a consistent version.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check service-worker support and registration
Service workers require a secure context. Angular identifies localhost as the development exception to the HTTPS requirement. Unsupported browsers do not receive Angular service-worker cache management or push behavior, so check SwUpdate.isEnabled before calling update methods that may reject. Angular notes that when support is unavailable, active calls such as checkForUpdate() can reject and related observables may not emit.
In standalone application setup, Angular’s provideServiceWorker() configuration accepts registration options. The current options include enabled, updateViaCache, type, scope, and registrationStrategy; enabled controls whether registration and related service-worker interactions are attempted. Review the SwRegistrationOptions API and Angular’s getting-started guide when configuring registration. The service-worker configuration guide covers the worker configuration file.
Use SwPush for Web Push, not app updates
For Web Push, SwPush exposes separate observables and methods:
messagesfor received push payloads.notificationClicksandnotificationClosesfor user interactions with notifications.pushSubscriptionChangesandsubscriptionfor subscription state.isEnabledto indicate whether push behavior is enabled.requestSubscription()to request a subscription using the server’s public key, andunsubscribe()to remove an active subscription.
A subscription request depends on browser support and user permission. It rejects if permission is denied, or if the browser blocks or does not support the Push API or service workers. These push events are not substitutes for SwUpdate.versionUpdates; use the service that matches the communication path. Angular’s SwPush API reference
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

