Question about "Notification (NSE) filtering" capability request

Question

Created 2w

Replies 1

Boosts 0

Participants 2

We are developing a messaging app which sends End-to-End encrypted data. The application supports multiple types of E2EE data, including text messages and voice over IP calls. Apple's article titled “Sending End-to-End Encrypted VoIP calls” (https://developer.apple.com/documentation/callkit/sending-end-to-end-encrypted-voip-calls) states that the following steps are required to support E2EE VoIP calls:

Request permission to receive remote notifications through the User Notifications framework
Register for VoIP calls using PuskKit
Add a Notification Service Extension target to your app.
Add the com.apple.developer.usernotifications.filtering entitlement to the NSE target’s entitlements file.

We have completed steps one through three. We are still missing the filtering entitlement. As of right now the system does not allow us to use reportNewIncomingVoIPPushPayload(_:completion:) method because of the missing entitlement.  Below is a short description of how our messaging app works:

User sends a message to another user.
The message is encrypted on device and sent to our server.
The server receives the message and sends a notification request to APNs if needed. The server cannot decrypt the message. As an additional security feature we do not pass the encrypted message in the notification payload. The notification payload only contains a localizable generic placeholder message string and default sound in the ‘aps’ dictionary part.
Upon receiving a notification from our server, the NSE makes a request to our server and fetches the latest messages (encryption keys have already been exchanged between the participants of the conversation) and determines what to do next (display a banner, or pass a call to CallKit).

E2EE VoIP calls are a core feature of our app, so it is imperative that we receive the filtering entitlement.

Our capability request has been rejected twice now. The latest request was rejected because:

Support for VoIP calls should be provided by PushKit. For more information, please consult the documentation page "Responding to Notifications from PushKit".

We cannot support VoIP calls by solely relying on PushKit. Our server cannot make a distinction when to use ‘voip’ (call) and ‘alert’ (text message) apns-push-types. Therefore, the application must be able to use reportNewIncomingVoIPPushPayload(_:completion:) function, where com.apple.developer.usernotifications.filtering entitlement is needed.

We have sent the above text to support two weeks ago and made yet another request.

Has anyone been able to get the capability as of late? What are the magic words that need to be included in the capability request? Can someone here help us? We made the first request on 3rd of September so this process has taken two months. Our planned release date is coming up and the absence of the capability is holding us back. We already have a released desktop and Android versions so changing the server implementation is really not an option.

Boost

Answer 1

Engineer OP

Apple

1w

The decision of whether the filtering entitlement is granted or not is solely in the hands of the entitlements team. Nobody here will have any involvement in granting or expediting the request.

If you feel like the filtering entitlement is something you cannot live without, you would need to make your case to the entitlements team.

That said, use of reportNewIncomingVoIPPushPayload() does not depend on the filtering entitlement. The filtering entitlement is only required to make the notification silent. You can still use the functionality of converting notifications to VoIP calls, although the notification will be visible.

By adapting your messaging in the notification (using the extension) to something that explains the situation and changing the interruption-level key in the payload to passive, so the notification will not interrupt a foreground app, or make a sound or light up the screen in most cases (while still being visible, though), you should be able to implement the functionality you are after, albeit without the ability to make the notification that turned into a call invisible.

If that ability is something you cannot live with, you would then need to make a case for your app with the entitlements team.

0