We are observing an issue where the iOS Notification Service Extension (NSE) is terminated by the system during startup, before either didReceive(_:withContentHandler:) or serviceExtensionTimeWillExpire(_:) is invoked. When this occurs, the notification is delivered without modification (for example, an encrypted payload is shown to the user). System logs frequently contain the message “Extension will be killed because it used its runtime in starting up”. During testing, we observed that CPU-intensive operations or heavy initialization performed early in the extension lifecycle — especially inside init() or directly on the main thread in didReceive often cause the system to kill the NSE almost immediately. These terminations happen significantly earlier than the commonly observed ~30-second execution window where the OS normally invokes serviceExtensionTimeWillExpire(_:) before ending the extension. When these early terminations occur, there is no call to the expiry handler, and the process appears to be forcefully shut down. Moving the same operations to a background thread changes the behavior: the extension eventually expires around the usual 30-second window, after which the OS calls serviceExtensionTimeWillExpire(_:). We also observed that memory usage plays a role in early termination. During tests involving large memory allocations, the system consistently killed the extension once memory consumption exceeded a certain threshold (in our measurements, this occurred around 150–180 MB). Again, unlike normal time-based expiration, the system did not call the expiry handler and no crash report was produced. Since Apple’s documentation does not specify concrete CPU, memory, or startup-cost constraints for Notification Service Extensions or any other extensions beyond the general execution limit, we are seeking clarification and best-practice guidance on expected behaviors, particularly around initialization cost and the differences between startup termination. NSE Setup: class NotificationService: UNNotificationServiceExtension { static var notificationContentHandler: ((UNNotificationContent) -> Void)? static var notificationContent: UNMutableNotificationContent? static var shoudLoop = true override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { NotificationService.notificationContentHandler = contentHandler NotificationService.notificationContent = request.content.mutableCopy() as? UNMutableNotificationContent NotificationService.notificationContent!.title = "Weekly meeting" NotificationService.notificationContent!.body = "Updated inside didReceive" // Failing scenarios } override func serviceExtensionTimeWillExpire() { NotificationService.shoudLoop = false guard let handler = NotificationService.notificationContentHandler, let content = NotificationService.notificationContent else { return } content.body = "Updated inside serviceExtensionTimeWillExpire()" handler(content) } }

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.

I am looking for advice for debugging a wallet pass not updating for some customers after successfully posting an APNS notification (pass identifier as topic, no expiration, priority 10). Is there an exhaustive list of reasons for a wallet pass not updating or a guide for making sure updates happen reliably? Are there are any guarantees made as to when the pass is updated? We noticed it is either never updating or the update happens much later for some customers. Usually toggling "Automatic Updates" in Pass Details updates the pass immediately for affected customers. Can it be caused by an error in the implementation of the Wallet Passes Web Service? We generate passes on the fly as a response to /v1/passes/{passTypeIdentifier}/{serialNumber}. I noticed that we also sometimes receive HEAD requests to this endpoint despite the documentation only mentioning the GET method. I was previously returning a HTTP status code 405 (Method Not Allowed). I have now updated it to also respond with headers (Content-Type, Content-Disposition and Last-Modified) for the pass for HEAD requests, but I don't know if it makes a difference. Here is a list of issues on the customer side I was thinking of: No connection to the internet Low power mode (does it prevent or throttle updates?) What happens if there is an error? Does it keep trying or does it just fail silently? In the latter case it might make sense to keep sending APNS notifications until the pass is requested successfully. I know that you can use the PassKit framework in iOS apps to update (replace) passes. Would this be more reliable than a stand-alone Wallet pass?

We are observing an weird behaviour where a user uninstalled the app back in February (more than a month ago) but APNs is still accepting push notifications are returning success responses. We know that using APNs response codes for uninstall tracking is not reliable and that Apple will use fuzzy schedule to invalidate tokens. However, showing successful responses for month+ old tokens seems a bit misleading and results in wasted token processing for both us and Apple. Could you please confirm that invalidation (or fuzzy schedule) could take more than months to invalidate tokens on the APNs side? Is that expected or is this a bug somewhere?

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?

Hi everyone, I'm developing a custom Apple Wallet pass using a Django backend and exposing my local server through ngrok during development. For the first ~30 minutes, everything works exactly as expected: the pass registers correctly, silent push notifications trigger instant updates, Wallet immediately performs the GET request to fetch the new .pkpass, and the changeMessage displays almost instantly on the lock screen. At some point, however, the pass stops updating entirely. Apple APNs continues to return 200 OK for every silent push I send, but the device never performs the required GET /v1/passes// call to download the updated pass. As a result, even the internal content of the pass (ex: points/balance fields) no longer updates, which confirms that Wallet is not fetching the new .pkpass at all. No changeMessage appears either. This behavior has been described informally by other developers as Apple Wallet Pass Update Throttling, where the Wallet daemon begins ignoring silent pushes after repeated updates or certain internal conditions. I’m trying to confirm whether this is indeed throttling, what triggers it, and how to avoid it during development.

Hello! When setting an alarm in an AlarmKit app, the alarm will not fire properly/reliably (the alert presentation is not shown) while the device has an app foregrounded in the landscape orientation. This behaviour has been present since the betas, however until the first party Reminders app showed the behaviour in the iOS 26.2 beta I suspected the issue was in my own code. The behaviour is exhibited when scheduling alarms in several AlarmKit apps: The Reminders app The AlarmKit WWDC Demo Project My own AlarmKit app However alarms scheduled by the stock Clock app do not seem to exhibit the behaviour. Minimal repro with first party app: Be using iOS 26.2 beta Open Reminders app Create an urgent reminder for a time in the not too distant future Open Mail.app Change to landscape orientation Wait for the fire time Observe the phone vibrates at the correct time but no alarm is fired Drag the notifications pane down, observe the LiveActivity has been started Change to portrait orientation Observe alarm fires I have noticed this behaviour from the AlarmKit apps mentioned while foregrounding other apps besides Mail, both first and third party: Photos YouTube Netflix The behaviour does not seem to occur when the foregrounded app is restricted to portrait mode, no matter the actual orientation of the device. In the case of my own app I have tried a multitude of ideas to get it to work reliably, getting alarms to fire in landscape is very intermittent at best and most often works after a fresh reboot. I've submitted a Feedback for the Reminders app: FB20956492. Any advice or suggestions would be appreciated!

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'm experiencing a critical regression on iOS 26 with a Notification Content Extension. extensionContext.open(uri) fails to open external URLs with LSApplicationWorkspaceErrorDomain Code=115 under specific conditions. Problem: When the main app is killed, and a rich push notification is received and expanded, tapping a button (specifically one with a transparent background, cornerRadius=0, clipsToBounds=false) fails to open its associated URL. Key Details: iOS 26 Only: Works perfectly on iOS 17, 18, etc. App Killed State Only: Works if the app is running (foreground/background). Works on Subsequent Notifications: The link will open if a second notification is received. LSApplicationQueriesSchemes: Confirmed to be correctly configured in the main app's Info.plist and present in the app bundle. Delay No Help: Adding a 1s delay before open(uri) does not fix it. My os_log statements confirm the button tap

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): Creates a UDP socket for call control (for SIP send/receive) VoIP App (callee): Creates a UDP socket for audio stream (for RTP send/receive) VoIP App (callee): Exchanges SIP messages (INVITE, 100 Trying, 180 Ringing, etc.) using the call control UDP socket VoIP App (callee): Answers the incoming call VoIP App (callee): Executes performAnswerCallAction() Immediately after executing performAnswerCallAction() in the above sequence, the sendto() function for both the "UDP socket for call control (SIP send/receive)" and the "UDP socket for audio stream (RTP send/receive)" occasionally returns errno = 57 (ENOTCONN). (of course The VoIP app itself does not close the sockets in this timing) Given that the user has performed an answer operation, the iPhone is in an active state, and the VoIP app is running, what could be the possible reasons why the sockets suddenly become unusable? Could you please provide guidance on how to avoid such socket closures? Our VoIP app uses SCNetworkReachabilitySetCallback to receive network change notifications, but no notifications regarding network changes were received at the time errno = 57 occurred. Is it possible for sockets used by an application to be closed without any notification to the application itself?

We have been getting several reports in the past 2 weeks of APNs notifications being either heavily delayed or not delivered at all. We have two apps, one of which has a Notification Service Extension and one of which does not. We have had users of both reporting sporadic notification problems. Looking at the sysdiagnose logs from one example, it looks like the notification was actually processed by our notification extension in a timely fashion, but was not displayed to the user. An example event we investigated it the following (now perhaps a little long in the tooth): 2025-10-31T14:32:54 apnsId=EE3E002D-26DE-B4F5-5E9B-5E0C1E1B6B3D We think we have correlated this with device logs: default 2025-10-31 10:32:54.472054 -0400 [EDE9521D-8A65-4588-8AE8-D3D78B9E5EA5] Received replacement content for notification request 859D-ABC7 [ hasContent: 1 attachments: 0 ] However there is no other reference until the app was launched about 1.5 minutes later: default 2025-10-31 10:34:26.875327 -0400 [..] Got 1 delivered notifications [ hasCompletionHandler: 1 ] When trying to reproduce, when I saw notifications bannered, the trace I saw was "Got 0 delivered notifications". What's the significance of "Got 1 delivered notifications" in this case? Historically, SpringBoard logs have shown detailed trace about the handling of notifications (which was very useful in narrowing down the slowness of notifications due to Apple Intelligence, reported on our side as FB16253547, which doesn't seem to have been triaged but it looks like was resolved around iOS 18.2.1 or iOS 18.3); however it seems that now sysdiagnoses are only containing <1 minute of trace from SpringBoard. Is there any way to extend the trace from SpringBoard that is included in sysdiagnoses? I see there was also https://developer.apple.com/forums/thread/806367 around the same time we started receiving reports. However I think my hypothesis is that this is a client-side issue, and notifications are being delivered to devices, just not presented correctly. Will try and collect a bit more data and file some Feedbacks and provide them here, but wanted to also flag here in case there are any others experiencing similar.

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.

My iPhone VoIP app, which I'm developing, uses Apple Push Notification service (APNs). I have a question regarding the following statement found in "[Overview of app transfer > Apps using push notifications]" Overview of app transfer You must manually reestablish push notification services if transferring an app that uses the Apple Push Notifications service (APNs). The recipient must create a new client SSL certificate using their developer account, as associated client SSL certificates, TLS certificates, and authentication tokens aren’t transferred. Question Let's say the recipient of the app transfer creates a "new SSL certificates, TLS certificates, and authentication tokens." Afterward, we need to verify that the Apple Push Notification service (APNs) works correctly when combining the transferred app with this "new SSL certificates, TLS certificates, and authentication tokens." However, until the recipient finishes verifying that it works correctly, the transferor want to keep the app available for download as before and be able to use the Apple Push Notification service. Is this possible? More specifically, can the recipient test the app to be transferred on TestFlight "before the transfer is completed"? I want to combine it with the "new SSL certificates, TLS certificates, and authentication tokens." and test it on TestFlight. Reading "[Initiate an app transfer]," it mentions the existence of a "Pending App Transfer" status. During this "Pending App Transfer" status, can the recipient test the app on TestFlight? Initiate an app transfer After you initiate the transfer, the app stays in its previous status, with the Pending App Transfer status added, until the recipient accepts it or the transfer expires after 60 days. Also, if there are any documents describing these procedures, I would appreciate it if you could share them. Thank you very much.

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") }

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.

Could anyone play a sound from the Library/Sounds directory using alarmkit? Same file can play in app bundle, but not available in Library/Sounds directory. Is this by design?

Dear Apple Engineer Recently we found that our push delivery rate has decreased. On the website "https://icloud.developer.apple.com/dashboard/notifications/teams/43Y657P48S/app/com.taobao.fleamarket", we found that starting from January 8, 2025, "Discarded - Token Unregistered" showed an upward trend, from millions to tens of millions. We have not found the reason, and hope you can help us. Team ID: 43Y657P48S Bundle ID: com.taobao.fleamarket Here are some failed tokens, in "Device Token Validator" The query is valid, but the user cannot receive the message: 56025f656cc3aa701898037f59e8d0cb937263ff5585cd1cec9ae661dcc15b19 5fbbd1e604d3662d7583e9377676f8fa276005145278d6dea04b4fc85a7b070e f0970602551f8d249d8f97960a74006ad78688b52fec6b0d19a585 207caff62e 9388fb40209c100afc2db728342f6fe86c7e34787a8fe4a92b73d2503c5286e0 a2819a4708462588b07452ed827d9afb03c343b586e70dcb67a9981f76295704 8949373cd43783fa3e23d38d55ee1fd72475b39f9c2d2fedca3ecb925b094240 Best Regards!

Hello, We are facing issue that sometimes a voip notification gets delivered after it is expired. The issue can be simply demonstrated we set the device to flight mode, and after 20s we disable flight mode. We still receive the voip notification. We are setting the expiration header as following apns-expiry=0, so from my understanding it should not be delivered if the device was not able to receive the notification in the fist attempt. I have read following thread https://developer.apple.com/forums/thread/778512, from which I understand this is a long standing issue. Hence my question is, is there any way how we can notify the call kit that the call is actually no longer valid, and do not display the call to the user at all? Currently we are forced to always display CallKit call when the notification comes, and some of our users are confused that they see a missed call which they did not have any chance to pick up. Please let me know if you need any more information. Best Regards, Adam Chlupacek

Hi, we've observed a weird behavior for a small amount of our user that we keep receiving the same token from APNs despite it's shown as Unregistered. When we try to send push to the token, we got an Unregistered error so we remove that token from our server. However, later we would receive an add token request from the client with the same token we just removed, and when we try to send to the token it returns Unregistered again so we remove the token again. This happened 3 times for a user in an hour. The identifierForVendor remains the same for all the requests. We also owns the client and I've checked client code that it's sending the token it received from didRegisterForRemoteNotificationsWithDeviceToken to the server.