Hey there, i implemented live activity in my app and iam trying to start the live activity from push notification, updates works fine even when the app is in background but starting the activity creating issue mostly on background and kill mode when i check the delivery of live activity on cloudkit console it says stored for device power considerations. anyone having the same issue ?

Hello, i'm facing issues, when trying to integrate push notification feature into my app. the following message is shown and I don't know how to fix it: ExportArchive "Runner.app" requires a provisioning profile with the push notifications feature (Encountered error while creating the IPA) Thankful for any help! Best regards

Hi all, We’re implementing in-app subscriptions in our iOS app using App Store Server Notifications V2 in the production environment. Everything is generally working well — we receive notifications such as DID_CHANGE_RENEWAL_STATUS, CANCELLATION, etc., and we log all incoming notifications into our own database. However, we've encountered a single case where the INITIAL_BUY notification was not received for a specific user. Interestingly, we did receive the later notifications (DID_CHANGE_RENEWAL_STATUS and CANCELLATION) for that same user. Here is our setup: App Store Server Notifications V2 Notification endpoint is stable and functioning normally (receives and logs other notifications) Notifications are reliably stored in our database The issue occurred only once for one user Environment: Production We've already contacted Apple Developer Support, but were informed that this issue is out of scope for direct support, and were directed to the Developer Forums. Our questions: Under what conditions might the INITIAL_BUY notification fail to be sent or delivered? Is there any known behavior or scenario where Apple may skip the INITIAL_BUY notification? Any recommendations on how to further investigate or verify whether it was sent from Apple’s side? We’ve confirmed that the notification never hit our server (no logs, no DB record), and our system was healthy at the time. Any insight would be greatly appreciated. Thank you!

SIM toolkit DISPLAY message is not displayed. Use case: SIP MESSAGE SMS Deliver (SC to MS) - 200 OK SIP MESSAGE RP-ERROR (MS->NW):111:Protocol error, unspecified Concatenated messages (2pcs) are resent over NAS and Deliver reports received from UE. User is not notified of SIM toolkit message.

In the app we are developing, we update the device token upon app launch using didRegisterForRemoteNotificationsWithDeviceToken. Previously, after an iOS major update, if the app was left without being launched, users experienced an issue where notifications would not be received. Later, we confirmed that running didRegisterForRemoteNotificationsWithDeviceToken during app launch updates the device token and restores the ability to receive notifications. Therefore, we believe that the device token may change due to an iOS major update. We want to understand the detailed conditions under which the device token is updated due to an iOS update: Does the same issue occur after iOS minor updates as well? Does it always happen during iOS major updates? We reviewed the official documentation, but there was no detailed description of the device token update conditions. Additionally, we contacted Apple, but received no clear answers. If anyone has experienced the same situation, we would appreciate any information you can share.

I need to create a background notification that counts down time and uses buttons to add or subtract time. Currently, I'm developing in React Native and using Expo Go to develop my app. I managed to display a simple notification, but I can't get it to work in real-time, so that when the time is up, it emits a sound indicating that the break is over. How can I implement this feature? My application now: My goal:

Facing issue while sending push notification through the application. The APNs certificate is valid. Below is the error log. System.AggregateException: One or more errors occurred. ---> PushSharp.Apple.ApnsNotificationException: Apns notification error: 'ConnectionError' ---> System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndSend(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndWrite(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.Security._SslStream.EndWrite(IAsyncResult asyncResult) at System.Net.Security.SslStream.EndWrite(IAsyncResult asyncResult) at System.IO.Stream.<>c.b__53_1(Stream stream, IAsyncResult asyncResult) at System.Threading.Tasks.TaskFactory1.FromAsyncTrimPromise1.Complete(TInstance thisRef, Func3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at PushSharp.Apple.ApnsConnection.<SendBatch>d__21.MoveNext() --- End of inner exception stack trace --- at PushSharp.Apple.ApnsServiceConnection.<Send>d__2.MoveNext() --- End of inner exception stack trace --- ---> (Inner Exception #0) PushSharp.Apple.ApnsNotificationException: Apns notification error: 'ConnectionError' ---> System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndSend(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndWrite(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.Security._SslStream.EndWrite(IAsyncResult asyncResult) at System.Net.Security.SslStream.EndWrite(IAsyncResult asyncResult) at System.IO.Stream.<>c.<BeginEndWriteAsync>b__53_1(Stream stream, IAsyncResult asyncResult) at System.Threading.Tasks.TaskFactory1.FromAsyncTrimPromise1.Complete(TInstance thisRef, Func3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at PushSharp.Apple.ApnsConnection.d__21.MoveNext() --- End of inner exception stack trace --- at PushSharp.Apple.ApnsServiceConnection.d__2.MoveNext()<---

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?

Hello Apple Developer Community, We’re building an MDM product (SaaS, multi-tenant). I’d like clarification on the APNs MDM push certificate usage model for service providers (MSPs). Question: Is it acceptable for an MDM vendor to use a single APNs MDM push certificate owned by the vendor to manage devices for multiple, independent customer organizations? Or is it required/recommended that each customer (company) must obtain and use its own APNs MDM push certificate (issued under the customer’s Apple ID) for their tenant? Why we’re asking: We understand that many guides show the process where each customer logs into the Apple Push Certificates Portal with their own Apple ID, uploads a CSR provided by the MDM, and then renews yearly. Practically, for a small team and early-stage deployments, using one vendor-owned certificate across multiple tenants would be simpler. We want to ensure we’re not violating any policy, terms, or technical requirements (e.g., certificate ownership, topic binding, device token isolation, audit/compliance expectations). What we need from Apple (or authoritative sources): An official Apple document or policy that clearly states whether per-customer certificates are mandatory vs strongly recommended for MSP/multi-tenant MDMs. If per-customer is mandatory, please point to the relevant clause or section. If a vendor uses a single certificate for multiple organizations, what risks or consequences should we expect (e.g., compliance issues, supportability, potential program violations, off-boarding problems, etc.)? Context: We’re sending only MDM wake notifications (standard MDM flow). We understand certificates expire yearly and must be renewed with the same Apple ID to avoid device re-enrollment. We want to follow Apple’s best practices while keeping early operations manageable. Any guidance, links to official documentation, or clarification from Apple engineers/moderators would be greatly appreciated. Thank you!

Observations​​: When our app calls the APNs API for push notifications, we observed significant fluctuations: July 15-25​​: The success response volume ​​increased by 20%​​ compared to the baseline before July 15. ​​After July 25​​: Success rates returned to baseline levels. July 30​​: Success response volume ​​decreased by 10%​​ compared to the pre-July 15 baseline. ​​ Excluded Factors​​: No changes in target audience size or characteristics (business factors ruled out). Server logs confirm consistent API request parameters and frequency. ​​Key Questions​​: Were there any ​​adjustments to response metrics​​ (e.g., success status code definitions) during this period? Have other developers reported similar issues? Were there server-side configuration updates or known incidents on Apple’s end?

We are observing unexpected behavior in Apple Push Notification Service (APNS) delivery and would appreciate clarification and guidance. Below is a detailed breakdown of the scenario and related questions. Abbreviations: APNP – Apple Push Notification Provider APNS – Apple Push Notification Service Scenario: User1 is registered on iOS device1. Flight Mode is enabled on iOS device1. User2 initiates a call to User1 (Time t = 0 sec). User2 cancels the outgoing call after 5 seconds (Time t = 5 sec). Flight Mode is disabled on iOS device1 after 20 seconds (Time t = 25 sec). Observation: iOS device1 displays an incoming call notification (CallKit UI) after flight mode is turned off, despite the call being cancelled by User2. This notification disappears automatically after approximately 8–10 seconds. Logic Flow: At time t = 0, our APNP sends a VoIP push (priority) to APNS for the incoming call. Since device1 is in flight mode, APNS cannot deliver the push. At t = 25 sec, after flight mode is turned off, APNS delivers the cached VoIP push to device1. The app takes ~5 seconds to initialize (CSDK setup, SIP registration, etc.). It eventually receives a SIP NOTIFY with state="full" and empty dialog info (indicating no active call). Consequently, the CallKit incoming call is removed after ~8 seconds. Questions: → We set the apns-expiration header to 0, expecting that the VoIP push would not be delivered if the device was unreachable when the push was sent. However, APNS still delivers the push 20–30 seconds later, once the device is back online. Q. Why is the apns-expiration header not respected in this case? → Upon receiving the VoIP push, we require ~10–12 seconds to determine if a visible CallKit notification is still relevant (e.g., by completing SIP registration and checking for active dialogs). Q. Is it acceptable, per Apple guidelines, to intentionally delay showing the CallKit UI (incoming call) for 10–15 seconds after receiving the VoIP push? → Apple documentation states that the priority VoIP push channel should be used only for notifying incoming calls, while regular (non-VoIP) pushes should be used for other updates, including call cancellations. Q. What is the rationale behind discouraging the use of the priority VoIP push channel for call cancellation events? In some cases, immediate cancellation notification is as critical as the initial incoming call. Would Apple consider it acceptable to occasionally use the priority VoIP channel for rare call-cancellation scenarios without risking throttling or suspension? → In our implementation, we send an incoming call notification via the priority VoIP channel. Shortly after, we send a call cancellation notification on the regular push channel, marked with "content-available": 1. We expect this regular push to wake the app (triggering application:didReceiveRemoteNotification:fetchCompletionHandler:), but in practice the app never wakes, and our debug logs inside that delegate method never appear. Q. Under what exact conditions does a "content-available": 1 regular push fail to wake the app when it follows a VoIP push? Are there additional requirements (e.g., background modes, rate limits, power optimizations) that could prevent the delegate from being called? → According to Apple documentation: “APNs stores only one notification per bundle ID. When multiple notifications are sent to the same device for the same bundle ID, APNs keeps only the latest one.” However, in our tests: If a device is offline when APNs receives both: (a) a priority VoIP push for an incoming call, (b) a regular push for call cancellation (same bundle ID), Upon the device reconnecting, APNs still delivers the earlier VoIP push, instead of discarding it and delivering only the most recent (cancellation) notification. Q. Why doesn’t APNs replace the queued VoIP push with the newer regular push when both share the same bundle ID? Is this expected behavior due to channel type differences (VoIP vs. regular), or is there a way to ensure that the latest notification (even if regular) supersedes the earlier VoIP push? We’d appreciate your input or recommendations on handling such delayed pushes and any best practices for VoIP push expiration handling and call UI timing.

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!

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

I created my app. One of its functionality is receive remote notification in the background (it receives it from Firebase Cloud Messaging via APNS) and replies with device location data. This is "boat tracking and alarm" type of app. It worked well both on my iPhone (where I use the same Apple ID as on developer's account) and on my son's iPad (different Apple ID). After the first review, when app was rejected with some remarks, background remote notifications completely stopped working on my iPhone. It looks like my iPhone put the app in permanent sleep. It never receives the background notifications. It receives them though in 2 case: when I open the app (it is no longer in background) when location is changed (it wakes app in the background). But the app should also respond when the device is stable at the position (I use both: precise and Significant Location Change. In the latter case changes are very rare). Btw, I scheduled a background task, not location, and it also never gets executed, so this workaround does not work. I describe it, so any Apple engineer does not get confused, verifying that these remote notifications reach the device. NO, they never get through when app is in the background (THIS IS THE PROBLEM), not that they are never delivered (the are, in the foreground). And the proof that it is not a problem with the app or remote notification construction is: they work on another drives (iPad) with no issues. Sometimes they are very delayed, sometimes almost instant. But usually they work. they worked the same way on my iPhone (with my developer's Apple ID) before the first rejection, and I haven't messed with messaging functionality since then. Now I am over with the last hope I had. I finally got my app release in App Store. I hoped official version would release some blockade my iOS put on my app. But unfortunately not. Official version works the same way as the test one. It works fine (receiving notifications in the background) on my son's iPad and it does not receive any background notification on my iPhone (100% block rate). Can anyone help me how can I reset my apps limits, the iOS created for my app? It seems that the rejection was a sparkle here - this is just a hint. I can provide any system logs for Apple engineers from both devices (iPhone and iPad) if you would like to check this case.

We operate a social network application, SportsYou with over 3 million monthly active users and are experiencing significant issues with push notification delivery through APNs. We have a large number of users reporting they are not receiving push notifications. Our infrastructure uses AWS SNS integrated with APNs to deliver notifications. However, AWS CloudWatch consistently reports successful delivery (Success response), even though users confirm they never received the notifications. Because we receive success responses from AWS SNS, our system does not attempt to recreate or refresh the device endpoints. This leaves us unable to detect or recover from these delivery failures automatically. This issue is widespread and inconsistent. It affects users across multiple variables including different iOS versions, different device models, and different versions of our application. We cannot identify a clear pattern that would help us isolate the root cause. With millions of active users, even a small percentage of delivery failures represents thousands of users experiencing a degraded service. This is significantly impacting user engagement and satisfaction. We need guidance on how to properly diagnose this issue and ensure reliable notification delivery to our users. Specifically, we'd like to understand why we're receiving success responses when notifications aren't being delivered, and what steps we can take to detect and prevent these failures.

I'm trying to rewrite a Swift code to Swift 6 language mode and am stuck with this problem. How do I safely pass the bestAttemptContent and contentHandler to the Task? This is from the UNNotificationServiceExtension subclass. final class NotificationService: UNNotificationServiceExtension { var contentHandler: ((UNNotificationContent) -> Void)? var bestAttemptContent: UNMutableNotificationContent? var customNotificationTask: Task<Void, Error>? override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { self.contentHandler = contentHandler bestAttemptContent = (request.content.mutableCopy() as? UNMutableNotificationContent) guard let bestAttemptContent = bestAttemptContent else { invokeContentHandler(with: request.content) return } do { let notificationModel = try PushNotificationUserInfo(data: request.content.userInfo) guard let templatedImageUrl = notificationModel.templatedImageUrlString, let imageUrl = imageUrl(from: templatedImageUrl) else { invokeContentHandler(with: bestAttemptContent) return } setupCustomNotificationTask( imageUrl: imageUrl, bestAttemptContent: bestAttemptContent, contentHandler: contentHandler ) } catch { invokeContentHandler(with: bestAttemptContent) } } // More code private func downloadImageTask( imageUrl: URL, bestAttemptContent: UNMutableNotificationContent, contentHandler: @escaping (UNNotificationContent) -> Void ) { self.customNotificationTask = Task { let (location, _) = try await URLSession.shared.download(from: imageUrl) let desiredLocation = URL(fileURLWithPath: "\(location.path)\(imageUrl.lastPathComponent)") try FileManager.default.moveItem(at: location, to: desiredLocation) let attachment = try UNNotificationAttachment(identifier: imageUrl.absoluteString, url: desiredLocation, options: nil) bestAttemptContent.attachments = [attachment] contentHandler(bestAttemptContent) } } } I tried using the MainActor.run {}, but it just moved the error to that run function. The UNNotificationRequest is not sendable, and I don't think I can make it so. Wrap the setupCustomNotification in a Task will move the errors to the didReceive method. It seems like the consuming keyword will help here, but it leads to a compilation error, even with the latest Xcode (16.2). Any pointers?

If I run the following code in didFinishLaunchingWithOptions() UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in if granted { DispatchQueue.main.async { application.registerForRemoteNotifications() } } } Then the result is that didRegisterForRemoteNotificationsWithDeviceToken() gets called. However if I change the code to be just: DispatchQueue.main.async { application.registerForRemoteNotifications() } Or as as its already running on main in this scenario, then just application.registerForRemoteNotifications() Then didRegisterForRemoteNotificationsWithDeviceToken() does NOT get called, but also neither does didFailToRegisterForRemoteNotificationsWithError(). Obtaining a push token is supposed to be independent of the user granting notifications permissions, so why am I not observing that behavior? I only observe this behavior when running on hardware, when running on the simulator both forms of the code work. Yet its nothing to do with my phone not being able to contact the Apple servers etc. - if I change the code back and forth back and forth between the two then if 100% works when using requestAuthorization() and 100% doesn't when not using it. There's nothing additional or out of the ordinary with the code, its standard app delete template stuff. Why isn't it getting a push token when requestAuthorization() isn't used? (I've tried adding an async delay to calling registerForRemoteNotifications(), but it made no difference).

Hello Team, We are currently experiencing an issue where some of our devices are not receiving push notifications. We are sending notifications via the Apple Push Notification portal (https://developer.apple.com/notifications/push-notifications-console/) using the following two requests. However, in both cases, the notifications are not being delivered to the devices. Scenario 1 : When we send a request with apns-push-type set to alert, we receive the following error. Request : curl -v --header "authorization: bearer ${AUTHENTICATION_TOKEN}" --header "apns-topic: com.testcompany.sampletest" --header "apns-push-type: alert" --header "apns-priority: 10" --header "apns-expiration: 0" --data '{"aps":{"alert":{"title":"Test Notification Title","subtitle":"Test Notification Sub Title","body":"Test Notification Body"}}}' --http2 https://api.push.apple.com:443/3/device/*devicetoken* Response: { "code": 400, "message": "bad-request", "reason": "The device token is inactive for the specified topic. There is no need to send further pushes to the same device token, unless your application retrieves the same device token.", "requestUuid": "c4ae39b4-87e1-4269-a1e9-163f60ec0385" } Scenario 2 : However, if we send the request with apns-push-type set to background, the request is processed successfully by APNs, but no notification is received on the device. Request : curl -v --header "authorization: bearer ${AUTHENTICATION_TOKEN}" --header "apns-topic: com.testcompany.sampletest" --header "apns-push-type: background" --header "apns-priority: 10" --header "apns-expiration: 0" --data '{"aps":{"alert":{"title":"Test Notification Title","subtitle":"Test Notification Sub Title","body":"Test Notification Body"}}}' --http2 https://api.push.apple.com:443/3/device/*devicetoken* Response: Getting a message that The notification sent successfully but no notification is received on the device. In both cases (with alert and background push types), the push notification does not reach the device. Additionally, when we validated the device token using the APNs Device Token Validator, it appears to be valid and returns the following message. "Device Token is valid for sending Alert & Background push-type notifications in the Production environment" Affected Device: macOS version : MacOS 15.3.1 Processor : Apple M1 Could you please assist me in resolving this issue? Thanks

We are observing a significant increase in 410 "Unregistered/ExpiredToken" responses from APNs when sending push notifications after 20 July. According to documentation, this indicates that the device token is no longer valid for the specified topic. However, the sudden spike raises questions about whether there have been any recent updates or changes to APNs' token invalidation logic. Could you please confirm: Whether there have been any recent updates in APNs behavior related to 410 responses? If there are best practices or recommendations for handling large volumes of token invalidations in order to detect uninstallations?

From iPhone iOS 18.3 , 18.3.1, and 18.4 Dev2, VIP Mail alerts will not wake a phone display to notify of a new mail received for a VIP contact. The phone will sound an audible tone indicating the mail was received, and if you manually wake the screen by tapping and then dragging upward to show notifications you will then see the VIP mail alert. However if the screen is sleeping, it will not light up or wake to indicate or display the new mail. The problem was briefly resolved in 18.4 Dev1, but problem returns in Dev2. We see this across all iPhone 16 Pros and iPhone SE2 with iOS 18.3 or higher. Is this something acknowledged by Apple as on track for resolution in iOS 18.4 Final Release? Thank you.