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.

以下の問題が発生しています： 特定のデバイスでプッシュ通知が受信されません。 考えられる原因は何でしょうか？ プッシュ通知は自社のサーバーから送信しており、APNs（Apple Push Notification service）からは正常な応答が返ってきています。 ユーザーはデバイスで通知が有効になっていることを確認しており、ネットワークの問題も報告されていません。 この問題は複数のユーザーに発生しています。

I’m testing remote push notifications on macOS, and although notifications are received and displayed correctly, my Notification Service Extension (NSE) never gets invoked. The extension is properly added as a target in the same app, uses the UNNotificationServiceExtension class, and implements both didReceive(_:withContentHandler:) and serviceExtensionTimeWillExpire(). I’ve also set "mutable-content": 1 in the APNS payload, similar to how it works on iOS — where the same code correctly triggers the NSE. On macOS, however, there’s no sign that the extension process starts or the delegate methods are called. import UserNotifications class NotificationService: UNNotificationServiceExtension { override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { let modified = (request.content.mutableCopy() as? UNMutableNotificationContent) modified?.title = "[Modified] " + (modified?.title ?? "") contentHandler(modified ?? request.content) } override func serviceExtensionTimeWillExpire() { // Called if the extension times out before finishing } } And the payload used for testing: { "aps": { "alert": { "title": "Meeting Reminder", "body": "Join the weekly sync call" }, "mutable-content": 1 }, "MEETING_ORGANIZER": "Alex Johnson" } Despite all correct setup steps, the NSE never triggers on macOS (while working fine on iOS). Can anyone confirm whether UNNotificationServiceExtension is fully supported for remote notifications on macOS, or if additional configuration or entitlement is needed?

I am using push notification in my app. User token gets properly registered and is sent to server. Notification are also sent by server and recieved on device as expected. The problem occurs when user uninstalls the app. iOS does not provide any option to handle uninstall event. On top of that when server send notification to such device token APNS feedback service sends success message. Meaning APNS sends push notifications to uninstalled app.I have an API to unregister the device on server since no event is triggered I am unable to call it.Please suggest a way out.

We are encountering the following issue with our VoIP application for iPhone, published on the App Store, and would appreciate your guidance on possible countermeasures. The VoIP application (callee side) utilizes a Wi-Fi network. The sequence leading to the issue is as follows: VoIP App (callee): Launches iPhone (callee): Locks (e.g., by short-pressing the power button) VoIP App (callee): Transitions to a suspended state VoIP App (caller): Initiates a VoIP call VoIP App (callee): Receives a local push notification VoIP App (callee): Answers the incoming call VoIP App (callee): Executes performAnswerCallAction() After this, the VoIP App (callee) uses "NSTimer scheduledTimerWithTimeInterval" to manage internal processing timing. However, the processing sometimes takes longer than the specified waiting time. Specifically, delays of several seconds can occur. We understood that if the user is interacting with the screen and both the iPhone and the VoIP app are in an active state, the VoIP app's processing would not be delayed. However, can significant delays (several seconds) in application processing still occur even when the iPhone is in an active state (i.e., the user is interacting with the screen)?"

I dont want my server to be spammed. Currently I am only in payment-related notifs (eg: user successfully renewed his subscription, user didnt successfully renew his subscriptions, ..) Where can I set that?

In didFinishLaunchingWithOptions I have this setup for getting the token to send to my server for notifications. The issue is that the delegate callback didRegisterForRemoteNotificationsWithDeviceToken gets called twice when also initializing a CKSyncEngine object. This confuses me. Is this expected behavior? Why is the delegate callback only called twice when both are called, but not at all when only using CKSyncEngine. See code and comments below. /// Calling just this triggers `didRegisterForRemoteNotificationsWithDeviceToken` once. UIApplication.shared.registerForRemoteNotifications() /// When triggering the above function plus initializing a CKSyncEngine, `didRegisterForRemoteNotificationsWithDeviceToken` gets called twice. /// This somewhat make sense, because CloudKit likely also registers for remote notifications itself, but why is the delegate not triggered when *only* initializing CKSyncEngine and removing the `registerForRemoteNotifications` call above? let syncManager = SyncManager() /// Further more, if calling `registerForRemoteNotifications` with a delay instead of directly, the delegate is only called once, as expected. For some reason, the delegate is only triggered when two entities call `registerForRemoteNotifications` at the same time? DispatchQueue.main.asyncAfter(deadline: .now() + 4) { UIApplication.shared.registerForRemoteNotifications() } func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { print("didRegisterForRemoteNotificationsWithDeviceToken") }

Hello, We are currently facing a persistent issue where Apple Push Notifications (APNs) are no longer being delivered to devices. This is not an intermittent problem — push notifications have completely stopped working. We are using PushSharp.Apple (Version 4.0.10.0) to send the notifications. Current Behavior (Failing): Every notification request appears to be processed successfully from the server side. However, the APNs client receives a 0-byte response, and the server closes the connection. Devices do not receive the notifications at all. Logs from Current (Failing) State: APNS-Client[1]: Connected (Batch ID=1) APNS-Client[1]: Sent Batch, waiting for possible response... APNS-Client[1]: Received 0 bytes response... APNS-Client[1]: Server Closed Connection... APNS-Client[1]: Disconnected (Batch ID=1) For Reference – Successful Log From Earlier (When Notifications Worked): APNS-Client[1]: Connected (Batch ID=1) APNS-Client[1]: Sent Batch, waiting for possible response... APNS-Client[1]: Received -1 bytes response... Push Notification Successfully Sent to Device Any help, suggestions, or experience with similar issues would be greatly appreciated. Thanks!!!

Having some discussion about when we should clear out a token from our servers. Docs say: Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. You can retry with a delay, if you get the error code TooManyRequests. The way I see it is that with the exception of PayloadTooLarge, all other errors means you should remove the token from your server. Either because: The token is no longer good The token is good, but this is just not the right: environment (sandbox vs production) topic (the token is from a different bundle id or developer team) target (app vs live activity appex) Do I have it right? Extra context: when using the "JSON Web Token Validator" tool, a colleague reported that a 410 -Expired token (from couple days back) was still valid today. This raises questions about when tokens should actually be deleted and how these error codes should be interpreted. Also is it possible for the docs to get updated for us to explicitly know if a token should get removed and not leave it for interpretation?

I'm encountering an issue with our legacy Objective-C codebase that uses UIApplicationDelegate. Here are the steps to reproduce the issue: Uninstall the application from the device. Install and launch the application. As part of the launch event, the client requests notification permission. The permission prompt is still displayed, even though the client receives a remote notification token (which appears to be a cached one). I followed the same steps with a sample app built with Swift (SwiftUI), and this issue did not occur. In the Swift app, I consistently received a delegate<didRegisterForRemoteNotificationsWithDeviceToken> call after the user allowed the notification permission. Could you please provide some insights into why this might be happening with only our client?

Hi Team, We are building oru subscrption app and want to rely on server side purchase / subscription related notifications. We went through https://developer.apple.com/documentation/appstoreservernotifications/enabling-app-store-server-notifications We wanted to understand the reliability and latency for server side notifciations provided by Appstore.

Hi, I’m looking for guidance on enabling push notifications for new emails in the native iOS Mail app (com.apple.mobilemail). Currently, I send push notifications using macOS Server (formerly OS X Server) Mail, but since it has been discontinued and renewal is no longer possible, I want to transition to the standard method used by email providers to notify the stock Mail app about new messages. To achieve this, I need access to the com.apple.mobilemail.push.com.zuplu APNs topic. This follows the same pattern used by other providers: iCloud: com.apple.mobilemail.push.com.me.mail.castle Fastmail: com.apple.mobilemail.push.com.fastmail Since Fastmail (as a third-party provider) has access to this, I assume there is a way for independent mail providers to integrate with XAPPLEPUSHSERVICE. In the interest of a free market and fair competition, I trust that Apple provides a means for email providers to notify the stock Mail app of IMAP server changes, allowing it to fetch new messages instantly. Under EU competition law, particularly Article 102 TFEU, dominant companies must not engage in anti-competitive behavior, including restricting access to essential services in a discriminatory manner. Furthermore, the Digital Markets Act (DMA) explicitly prohibits gatekeepers from favoring their own services or restricting interoperability without justification. Any insights or official guidance would be greatly appreciated! Thanks, DragonWork

I'm running into an issue during the iOS build process for my app, and I'm hoping someone can point me in the right direction. ❗ The Problem When attempting to archive the app via EAS Build (Expo), the build fails with the following error: `Provisioning profile "HCF_AppStore_ProvisioningProfile" doesn't include the com.apple.developer.push-notifications entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update.` What I’ve Already Done: Enabled Push Notifications capability for the App ID (com.rsmco.helpcreatefamilies) in the Apple Developer portal. Deleted and regenerated the App Store Provisioning Profile after enabling the capability. Confirmed the new profile is associated with the correct App ID and Distribution Certificate. Uploaded the new profile to EAS (Expo) and rebuilt the app. Yet the error persists during the Xcode archive step with Exit code 65. Additional Info: Provisioning Profile Name: HCF_AppStore_ProvisioningProfile App ID: com.rsmco.helpcreatefamilies Team: Reproductive Sciences Management Company, LLC Workflow: Expo EAS Build Capability causing issue: com.apple.developer.push-notifications

I submitted the form for the critical alert entitlement but have not received any response for already 2 weeks. How long does it normally take to review such requests? Is there any way I can contact a certain department directly?

we already got access to com.apple.developer.usernotifications.filtering , we have set up this special permission in our app extension entitlement and provision profile. but we are still unable to filter notification by providing empty UNNotificationContent

We recently developed the provisional permission for our app, but we have noticed that is not working as expected in iOS 16 (We have tested only there). Currently we request the permissions like this: UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound, .provisional]) { [weak self] _, _ in // here we register for pushes in case authorizationStatus is provisional or authorised } What happens is we do get the 1st notification with the keep CTA - once tapped we see that there pops an action: "Deliver Immediately", but even though the user selects that, we still see under setting the pushes are marked as "Deliver Quietly". In addition to this the sound and bage still stay as toggled off - and the lock screen and banner as well stay off. Basically, nothing changes after the user selects "Deliver Immediately"

Push message on the lock-screen disappears in one specific instance. In general the situation is as follows: the application, upon starting up, sets the badge counter (i.e. notificationCenter.setBadgeCount(3)) the application is being sent to background the screen is locked (it doesn't matter if it's turned on or not) send a push message to the application and set the badge (in aps) to "0" What happens: the screen lights up (unless it's lit up already), the push is being displayed for a very short time and gets hidden. Happens on iOS 18.1, 18.1.1, 18.2. If not setting badge in the aps keys it works correctly. I've created a feedback report https://feedbackassistant.apple.com/feedback/16095572. I am able to reproduce the issue on a sample app 100% of the time :/

How do i add the red bubble badge notification on the app for unread in app messages

We are currently developing a WebAPI service that uses APNs (HTTP/2) to send push notifications to iOS devices. (Using PushSharp's HTTP/2 support) The WebAPI service is running on IIS using .net framework 4.8 and c#. The connection to APNs is always maintained, and the connection is checked every 30 minutes using a dummy token Ping. KeepAlivePeriod = 30 minutes and KeepAliveRetryPeriod = 10 seconds have also been set. However, the following issues are occurring. Although the Ping sent immediately before was successful, a TimeoutException occurs in the notification request sent a few minutes later. There is no explicit disconnection notification from APNs, and the connection appears to be silently disconnected. Once a TimeoutException occurs, it occurs frequently afterwards. Below is an excerpt from the log. Apple Notification Failed for some unknown reason 1-1: One or more errors occurred. Apple Notification Failed for some unknown reason 1-2:System.TimeoutException: The operation timed out. In light of this issue, I would like to be advised on the following two points. Are there any official specifications regarding the lifecycle and expiration date of APNs HTTP/2 connections? Even if pings are sent periodically, is there a timeout or other setting that disables the connection on the APNs side? What are the conditions that would cause APNs to silently terminate a connection? For example, could this be due to inactivity, TLS restrictions, network maintenance, etc.? If you have any official documentation or technical guidelines to improve the reliability of this system, we would appreciate it if you could share them with us. Thank you in advance.

I am experiencing an issue with push notifications on my iOS application. The issue is as follows: On Android devices, push notifications are received immediately without any problems. On iOS devices, the behavior is inconsistent: When the app is in the foreground, notifications are received immediately. When the app is in the background or in recent apps with a significant delay of 5–10 hours, push notifications are not received at all. This behavior creates a major challenge for us, as timely notifications are critical for our app’s functionality. We have already verified the following points on our side: Push notification certificates and APNs setup are correct. Payload and server configurations are valid, as notifications are working fine on Android. No restrictions from the server-side, since Android users receive notifications instantly. It seems the issue is specifically related to iOS devices or APNs delivery. Could you please help us identify the cause and provide guidance on how to resolve this?