Notification attribution for PWAs on macOS

at a glance

syntax

This feature adds no new syntax — the existing Notifications and Badging entry points are the trigger surface, and attribution is decided by Chrome from the posting context:

// Triggers (unchanged web API surface):
new Notification(title, options);                    // page context
serviceWorkerRegistration.showNotification(title, options);
navigator.setAppBadge(contents); / navigator.clearAppBadge();

// Local testing switch (macOS only), compiled under BUILDFLAG(IS_MAC):
chrome://flags/#enable-mac-pwas-notification-attribution

Whether a given call is attributed depends on the requirements — the developer does not opt in or out per call.

why it exists

Before this change, every notification a PWA posted on macOS was displayed under the “Google Chrome” umbrella: Chrome's name, Chrome's icon, and Chrome's single entry in macOS notification settings. Users could not manage notification settings — sounds, badges, alert style, Focus modes — on a per-PWA basis, which the ChromeStatus motivation calls “a highly requested native integration on macOS”.

Routing delivery through the PWA's app shim (the small per-PWA .app bundle Chrome installs on macOS) gives each PWA its own identity with the operating system. Because macOS attributes a notification to the bundle that posts it, the PWA's name and icon appear in Notification Center and it gets its own entry in System Settings → Notifications, aligned with how native macOS applications behave.

how it works

The attribution is a delivery-path change inside Chrome and the app shim, verified against Chromium source:

1. Routing. When a web page or service worker that maps to an installed PWA posts a notification, Chrome connects to a MacNotificationProvider in the PWA's app shim process (AppShimManager::LaunchNotificationProvider(app_id) in app_shim_manager_mac.h). If no shim is currently running, the call returns a remote connected to a dummy notification provider — the header documents a future change to instead launch the shim on demand.
2. Shim-side delivery. The shim runs its own MacNotificationServiceUN bound to UNUserNotificationCenter.currentNotificationCenter (AppShimController::BindNotificationService in app_shim_controller.mm). Because the request is posted from the shim's own process and bundle, macOS attributes it to the PWA.
3. Per-app OS permission. The app shim owns an operating-system-level notification permission of its own: AppShimManager::ShowNotificationPermissionRequest(app_id) triggers the OS prompt shown by the shim, and the result drives the web permission flow (see permission model).
4. Badging. AppShimManager::UpdateAppBadge(profile, app_id, badge) routes the app badge to the shim as part of the same integration (see app badging for the new permission gate).

Nothing in the Notifications or Badging web IDL changes. Web pages use the same Notification constructor, ServiceWorkerRegistration.showNotification(), and navigator.setAppBadge() calls as before; what changes is which process delivers them and which bundle macOS credits.

requirements: when attribution applies

Attribution is not unconditional. Chromium gates it on all of the following (WebAppTabHelper::GetAppIdForNotificationAttribution in web_app_tab_helper.cc, and AppShimController::WebAppIsAdHocSigned / ShouldCreateNotificationServiceUN in app_shim_controller.mm):

If any condition fails, notifications fall back to the previous behavior: delivered by Chrome itself and attributed to “Google Chrome”.

the two-layer permission model

With attribution active there are two permission layers for an installed PWA:

Chrome wires the layers together in the permission prompt path (permission_prompt_notifications_mac.cc): when the web permission prompt runs for an attributed app, Chrome first asks the shim for its OS-level result —

• kPermissionGranted → the web prompt is accepted.
• kPermissionPreviouslyDenied → the web prompt is ignored (no prompt shown) and Chrome records NotificationsWasDeniedBecauseOfSystemPermission in page-specific content settings.
• kPermissionDenied → the web prompt is denied.

Practical consequence: once the user has denied the PWA at the macOS level, Notification.requestPermission() in that PWA no longer shows a prompt — recovery is only through System Settings → Notifications (or an MDM profile, for managed devices).

behavior contracts

The three developer- and administrator-facing contracts of this change each have a dedicated reference page:

• requireInteraction not honored for installed PWAs — notification persistence becomes a per-app macOS user setting; the web API field is ignored for attributed PWAs.
• App badging requires notification permission — navigator.setAppBadge() silently does nothing unless the PWA has notification permission.
• Enterprise pre-grant now requires MDM — the Chrome NotificationsAllowedForUrls policy must be paired with a macOS MDM configuration profile per PWA bundle ID.

Both web-facing changes deliberately match the already-shipping behavior of installed web apps in Safari on macOS, per the PSA (“Both of these changes match the already shipping behavior in WebKit”).

examples

There is no new API to call — the change is behavioral. What a developer can do is (1) stop depending on requireInteraction for macOS PWAs and (2) gate badge updates on notification permission:

// Notifications: do not rely on requireInteraction persisting the alert
// for installed PWAs on macOS — the user's per-app setting decides.
const reg = await navigator.serviceWorker.ready;
reg.showNotification("Order ready", {
  body: "Pick up at counter 3",
  // Still fine to set for other platforms; ignored by macOS PWA attribution:
  requireInteraction: true,
});

// Badging: macOS PWAs now silently ignore setAppBadge() without
// notification permission, so check first.
async function updateBadge(count) {
  if (!("setAppBadge" in navigator)) return;
  if (Notification.permission !== "granted") return; // macOS no-op guard
  await navigator.setAppBadge(count);
}

ChromeStatus also links a Notifications API PWA-testing sample.

web platform tests

There is no WPT coverage specific to this change: the attribution is browser-shell behavior with no web-exposed surface to assert against, and the PSA describes the behavioral changes as “not directly web-exposed”. The host-API suites continue to exist and are unaffected in scope:

• notifications/ — constructor, event, and permission tests for the Notifications API.
• badging/ — setAppBadge/clearAppBadge success, error, and IDL harness tests. None assert a notification-permission gate (that gate is Chrome-on-macOS PWA behavior, not spec behavior).

browser compatibility

Interim table. BCD has no entry for the attribution behavior itself (it is browser-shell behavior, not an API member); the host APIs are covered. Rows below cite the linked BCD files verbatim, with the Chrome 152 macOS change annotated from the milestone listing and PSA.

security and privacy

• Attribution is identity-strengthening, not a new channel. Notifications a PWA already could show are now credited to the PWA's own bundle; no new data leaves the device and no new web-exposed surface is added (the PSA calls the changes “not directly web-exposed”).
• Per-app OS control. Users gain macOS-level control per PWA — alert style, sounds, badges, Focus modes — under System Settings → Notifications, which they previously only had for Chrome as a whole (the stated motivation).
• OS denial wins. A PWA whose macOS-level permission was denied cannot re-prompt from the web; Notification.requestPermission() is ignored and Chrome records the denial reason (NotificationsWasDeniedBecauseOfSystemPermission) for UI surfacing.
• Signing boundary. Attribution only happens for ad-hoc-signed shims (WebAppIsAdHocSigned()), so notification identity is tied to a shim bundle Chrome itself created and signed at install time.
• Managed devices. Enterprise pre-grants now span two trust domains (Chrome policy + macOS MDM); see enterprise deployment for the exact requirements.

specifications

There is no specification document for the attribution mechanism itself — it is an implementation detail of Chrome's macOS app shim layer; the authoritative records are the PSA, the ChromeStatus entry, and the linked Chromium source.

see also

• Chrome Platform Status — Notification attribution for PWAs on macOS (API record)
• blink-dev — Web-Facing Change PSA: Notification attribution for PWAs on macOS
• Chromium tracking bug 327449602
• MDN — Notifications API and MDN — Badging API (host APIs; neither documents this macOS attribution behavior — checked 2026-07-29)
• Chrome Platform Showcase — interactive demos for this feature
• googlechrome.github.io — Notifications API PWA-testing sample