Can the notification filtering entitlement be used to clear notifications read on another device?

Question

Created 1w

Replies 1

Boosts 0

Participants 2

We make a messaging and calling app (Call.com). When a user reads a chat on another device (web or another phone), we want that chat's notifications removed from their iPhone's lock screen and Notification Center.

Our plan is a Notification Service Extension that receives a "message read" push, removes the matching delivered notifications with removeDeliveredNotifications(withIdentifiers:), and then hides the read push itself by passing an empty UNNotificationContent to the content handler. The read push carries only a conversation ID and a message ID, with no message content. Hiding it needs com.apple.developer.usernotifications.filtering.

The entitlement request form offers four use cases. The closest is end-to-end encrypted messaging, but it doesn't apply to us: our server can read notification content. So we don't think we should select it.

We tried a background push (content-available: 1, sent through FCM) first. We tested on a physical iPhone with Background App Refresh on and the app running in the background (not force-quit). The device log showed the push being deferred: a com.apple.pushLaunch.<bundleId> activity was submitted with a 24-hour window. A second background push sent about 190 ms later cancelled that pending activity. The app never ran, and the notification stayed on the lock screen for the 8 minutes we watched.

Questions:

Can the filtering entitlement be granted for this use case, or only for the four listed ones?
If not, what is the recommended way to remove delivered notifications after the user reads them on another device? Is a background push the only supported option?
If a background push is the answer, what can we do to make it more reliable? For example, would sending one background push per read event instead of two help?

Thanks!

Answer 1 · 1w

Pokpong OP

1w

I would not assume this entitlement will be granted for this use case. The four options on the request form are a guide, but Apple decides eligibility. Since your server can read notification content, describe that accurately and ask Apple Developer Support whether the use case qualifies. Do not select end-to-end encrypted messaging if it does not apply.

removeDeliveredNotifications(withIdentifiers:) can remove notifications your app already knows about, but your code has to run on the device. A silent push is only a best-effort background wakeup. iOS can delay, coalesce, throttle, or omit it, so it cannot guarantee prompt cleanup. A notification service extension is for modifying an eligible visible notification with mutable-content; it is not a general handler for a data-only read event. Empty content filtering also depends on the entitlement.

If you use background pushes, send one compact update per conversation where possible, make handling idempotent, and treat the push as a hint to fetch current read state rather than an event that must arrive. Reconcile again when the app next runs. This improves consistency but still cannot guarantee immediate removal while iOS does not run your app.

See Apple's docs for removing delivered notifications, background updates, and notification service extensions.