I'm having a reproducible problem receiving push notifications on macOS 26.2. The pattern is that the push is received and then discarded almost immediately (there is a 60s expiration date) when on battery power and then when I plug in pushes start working and even if I unplug again it works for hours until breaking again. These are alert notifications with priority 10. Other team members have had similar problems but less reliably broken and even get a "stored for device power considerations" message followed by discarded (see apns-unique-id c29250a3-abbf-008a-96f9-a5384e32d1df). An example from my machine with the apns-unique-id 6b2dfe3d-af99-182a-0e1e-6b811d3ec486 which fails immediately. iOS is working fine however so this seems to be confined to macOS only.

Hi there, we noticed high volume of 410 responses from APNs. It started on July 19th and we see it across multiple apps. Is there some sort of mass token invalidation/removal that's happening on APNs?

When setting a custom sound in AlarmKit, the alarm only plays the audio file once. I can understand why push notifications would play a sound only once, but I don’t understand why alarms can only play the sound for less than 30 seconds. We’re already at beta 6, so I’m wondering if Apple still hasn’t fixed this or if they have no intention of fixing it.

I created new APNS key, when i clicked on download, this is the error am getting: Download Failed Auth Key can only be downloaded once. This auth key has already been downloaded. I dont have any key before and i have not downloaded the key before, it just a new key, i just created. Please this is affecting the release of our client app, and the client is having negative thought concern our service not knowing it from you guys.

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?

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 :/

sending the following POST request: ---- HTTP REQUEST ---- POST https://appleid.apple.com/auth/token Headers: Content-Type: application/x-www-form-urlencoded Body: client_id=au.com.thejlrguy.businesschat&client_secret=eyJhbGciOiJFUzI1NiIsImtpZCI6IktLUDc4MkhGVTcifQ.eyJ...QeDn7ug&grant_type=client_credentials&scope=https%3A%2F%2Fappleid.apple.com Getting the below error: {"error":"invalid_client"} The private key used to sign the JWT was created 24 hours ago.

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.

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?

Hi Apple Dev Team, We have a React Native application that includes call functionality using PushKit and VoIP notifications. We are using APNS to send the VoIP notifications, and everything has been working smoothly on iOS versions up to 18.3.1. However, after updating to iOS 18.4, we are no longer receiving incoming VoIP push notifications on the device. There have been no code changes related to our PushKit or notification logic — the exact same build continues to work correctly on devices running iOS 18.3.1 and earlier. We're trying to understand if anything has changed in iOS 18.4 that affects VoIP push delivery or registration behavior. Would appreciate any guidance, and happy to share code snippets or configuration if needed. Thanks in advance!

Docs mention the following about the timestamp field returned by APNs: "The time, represented in milliseconds since Epoch, at which APNs confirmed the token was no longer valid for the topic. This key is included only when the error in the :status field is 410." We would like to clarify whether this timestamp is subject to the fuzzy schedule or whether it represent the accurate time of when APNs knew that the token became invalid? We understand that using 410 for tracking purposes is off label. However we still would like to have the most accurate information in regards to when token became invalid. This will help us debug user issues better in cases when they re-install, uninstall, change permission settings, etc.

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?

Hi team, I am developing VOIP feature using PushKit and CallKit but CallKit is not show when app in background or terminate state, now in foreground state I can call reportNewIncomingCall from pushRegistry-didReceiveIncomingPushWith and it's work as expected but the problem is in background or terminate state it's not my setup: PushKit is configured In Signing & Capabilities I add background modes (Remote notifications and Voice over IP) In info.plist I add <key>UIBackgroundModes</key> <array> <string>voip</string> I'm not sure should I create new VOIP Certificate but now I can receive message notification normally. Any help or suggestions would be greatly appreciated Thank you

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!

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.

Our mobile app uses a specific platform for subscription management. At this time,, it's integration with Apple notifications is built around the Server-to-Server Notifications v1 and the traditional verifyReceipt endpoint. At this time, it does not support Server-to-Server Notifications v2, nor has any published documentation or resources on a custom integration path using v2. Our app is built using Flutter and we handle purchases with the in_app_purchase plugin. However, due to the limitation on the system for subscription side, we need to connect to Apple’s legacy server-to-server subscription endpoints (StoreKit v1) to receive real-time notifications and validate receipts. Could you please provide information how to do it?

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!

I am sending push notification using HTTP/2 to https://api.push.apple.com:443 api but I am getting Operation TimeOut error in response . Can someone help

Hi all, I’m running into an issue with provisioning profiles not including the com.apple.developer.push-notifications entitlement — even though everything seems to be configured correctly. Here's what I’ve done: Checked the App ID has Push Notifications enabled. I’ve clicked “Configure” and created a Production APNs certificate under the App ID. I’ve regenerated the provisioning profiles (Ad Hoc and App Store). I can see within the profiles within App Store Connect that the push notifications capability is listed I’ve downloaded and decoded the profiles using: security cms -D -i profile.mobileprovision &gt; decoded.plist But com.apple.developer.push-notifications is still missing under the &lt;key&gt;Entitlements&lt;/key&gt; block. This is causing issues because: When I submit the build to eas I receive this error from XCode: - Provisioning profile "*** Adhoc" 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. (in target '***' from project '***') Refer to "Xcode Logs" below for additional, more detailed logs. To isolate the issue further I: Created a completely new App ID, enabling Push Notifications from the start. Created new APNs certificate. Generated new provisioning profiles with a valid distribution certificate. Still no push entitlement embedded in the profile. Question: Has anyone else encountered this issue where Push Notifications are enabled and configured, but the entitlement still fails to embed in the profile? Thanks in advance.

After updating to iOS 26 beta 1, I can't receive any push notifications from most applications. I can receive notifications from like Calendar, which uses local & reserved notifications, but I can't receive any remote-based notifications.