requireInteraction is not honored for installed PWAs on macOS

syntax

The web API surface is unchanged — the field still exists and is still specified:

// Notifications API (WHATWG) — NotificationOptions.requireInteraction
new Notification(title, { requireInteraction: true });
serviceWorkerRegistration.showNotification(title, { requireInteraction: true });

The WHATWG Notifications Standard defines requireInteraction as a notification's require interaction preference (a boolean, initially false): “When true, indicates that on devices with a sufficiently large screen, the notification should remain readily available until the end user activates or dismisses the notification.”

inputs

Scope of the change, per the PSA: “For installed PWAs, Chrome will no longer support the requireInteraction field for notifications.” Notifications posted by ordinary (non-installed) tabs in Chrome on macOS are not affected by this feature — they continue to be attributed to Google Chrome and keep the pre-152 behavior.

outputs

• The Notification object is still created and its requireInteraction getter still reflects the value passed in the options — the field is not removed from the API.
• The observable difference is at the OS level: an attributed PWA notification's on-screen persistence follows the PWA's macOS alert-style setting (“None” / “Banners” / “Alerts”), regardless of the field's value.
• Per the PSA, this “matches the already shipping behavior in WebKit” for installed web apps on macOS.

errors

None. Passing requireInteraction never throws and produces no console warning — it is silently ignored for attributed PWAs. There is no programmatic signal that the preference was disregarded; developers should treat the field as advisory on this platform.

context and exposure

Applies only when all attribution requirements hold: macOS, the feature enabled (default in 152), the app installed with OS integration, an app shim registered, and the shim ad-hoc signed — see the requirements table. When any condition fails, the notification is attributed to Google Chrome and requireInteraction behaves as before.

There is no web-exposed capability detection for “is this notification attributed?” — no API reports which delivery path was used. A pragmatic proxy is to check whether the page is running as an installed PWA (matchMedia('(display-mode: standalone)')) on macOS Chrome 152+ and avoid depending on the field there.

lifecycle

1. The web app creates the notification (page new Notification() or service worker showNotification()) with requireInteraction set.
2. Chrome resolves the posting context to an installed app id (GetAppIdForNotificationAttribution) and routes delivery to the PWA's app shim notification provider.
3. The shim posts a UNNotificationRequest to UNUserNotificationCenter.currentNotificationCenter. macOS applies the PWA's per-app notification settings — including alert style — with no channel for the app to request persistence.
4. The alert auto-dismisses or stays per the user's setting; activation/dismissal events flow back through the shim's action handler to the service worker as usual (notificationclick, notificationclose).

examples

// Before (pre-152 macOS / other platforms): alert persists until dismissed
reg.showNotification("Incoming call", {
  body: "Ada is calling",
  requireInteraction: true,
});

// Chrome 152+, installed PWA on macOS: same code, different outcome.
// The field is ignored; the user's per-app alert style decides.
// Robust pattern: don't encode "must persist" in the notification —
// surface critical state in-app as well.
const isMacPWA =
  matchMedia("(display-mode: standalone)").matches &&
  /Mac OS X/.test(navigator.userAgent);
if (isMacPWA) {
  showInAppRingUI(); // your own unmissable surface
}
reg.showNotification("Incoming call", { body: "Ada is calling" });

Try it in the Chrome Platform Showcase notification capability lab (route HEAD-checked 200, 2026-07-29).

browser compatibility

From BCD api/Notification.json (fetched 2026-07-29), with the macOS attribution change annotated — BCD itself has no entry for the attribution behavior:

security and privacy

• User control over app control. Persistence moves from a per-notification app decision to a per-app user decision — users can no longer be forced to keep an alert on screen by an installed PWA on macOS.
• No fingerprinting surface added. The field continues to be accepted identically; there is no signal exposing whether attribution is active or which alert style the user chose.
• Do not compensate invasively. Because the platform intentionally removes the persistence guarantee, workarounds that try to recreate it (wake-lock tricks, re-posting loops) fight the user's explicit OS-level choice.

specifications

see also

• Notification attribution for PWAs on macOS — overview
• App badging requires notification permission
• Enterprise deployment (MDM pre-grant)
• ChromeStatus 5863296436666368
• MDN — Notification.requireInteraction (API reference; does not document the macOS attribution behavior — checked 2026-07-29)