I am unable to connect to APNs sandbox push endpoint from our backend servers. It works fine when hitting the request from my local machine but it fails from the infra servers. Here are the complete curl details. Endpoint: https://api.sandbox.push.apple.com:443 CURL request and response: curl -v https://api.sandbox.push.apple.com:443 Trying 17.188.168.149:443... Connected to api.sandbox.push.apple.com (17.188.168.149) port 443 ALPN: curl offers h2,http/1.1 Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH TLSv1.2 (OUT), TLS handshake, Client hello (1): CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.sandbox.push.apple.com:443 Closing connection curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.sandbox.push.apple.com:443 There are no issues with Production endpoint. Can someone help? Verified all certificates. Everything worked fine until 29th July but started failing since 30th July

The docs are conflicting. https://developer.apple.com/documentation/activitykit/starting-and-updating-live-activities-with-activitykit-push-notifications#End-the-Live-Activity-with-a-custom-dismissal-date says: When you end a Live Activity, by default the Live Activity appears on the Lock Screen for up to four hours after it ends to allow people to glance at their phone to refer to the latest information. However here it says: https://developer.apple.com/documentation/activitykit/displaying-live-data-with-live-activities#Understand-constraints A Live Activity can be active for up to eight hours unless its app or a person ends it before this limit. After the eight-hour limit, the system automatically ends the Live Activity, and immediately removes it from the Dynamic Island. However, the Live Activity remains on the Lock Screen until a person removes it or for up to four additional hours before the system removes it — whichever comes first. As a result, a Live Activity remains on the Lock Screen for a maximum of 12 hours. So is it 4 hrs OR '8 for Dynamic Island vs 12 for Lock Screen'?

I'm developing an app which will show the driver ETA and rendering the progress bar of the current ETA. Intuitively the backend server sends the push notification every 3 seconds through firebase cloud message service to APNS so that the device can refresh the dynamic island smoothly. But the live activity doesn't refresh as frequently as the backend service does. It should refresh every 3 seconds but it turns out like refresh 30 ~ 60 seconds, sometimes it didn't refresh at all. any body facing the same?

Hey there, i start a live activity with notification , and but sometime it can not update, it happens sometime and make me so confuse; like about 2025-08-19 +8.0 09:20:52 updatetoken : 40ead3fd4dd4a934548c5455c645fc6920edfaa0ddad98abd619dc1d2662389c15d3dc3b420bdec733d9438d25ae61cb55601ae64292b3064a71ffb8d0355633f3f0f2254e6f7438282ce83366d8430c app can not accept push update msg, and APNs has show success when server send update msg to APP; how can i check the APNS to APP? Thanks

Good day) Colleagues, please tell me how can I change the notification on the locked screen "pass changed" in PKPASS when changing several fields? Thank you very much for your answer

I'm developing an app which will show the driver ETA and rendering the progress bar of the current ETA. Intuitively the backend server sends the push notification every 3 seconds through firebase cloud message service to APNS so that the device can refresh the dynamic island smoothly. But the live activity doesn't refresh as frequently as the backend service does. It should refresh every 3 seconds but it turns out like refresh 30 ~ 60 seconds, sometimes it didn't refresh at all. any body facing the same?

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.

Good day) I am developing an application for generating PKPASS in Java. PKPASS itself is generated and installed on the device and updated. But I encountered a problem. When sending information about the update to the APNs service, PKPASS is updated, but the push notification is not shown on the device. On the device, all tooltypes are set to receive the update. As well as the basic settings: We go to the APNs service using = JWT token. "apns-push-type"= "alert" "apns-topic" = PassTypeIdentifier payload = {} I would also like to add that we send push notifications to the production environment. P. S. Six months ago, push notifications came

"Auth Key can only be downloaded once. This auth key has already been downloaded."

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?

Starting Xcode 14, iOS Simulator is able to communicate with APNs in order to register for notification in the sandbox environment. I created a sample test for this. A dumb iOS application that registers for notifications. It has UITests to automatize the tap on the consent popup (it is not possible to ask for the permission via CLI sadly). Once the application registers, the AppDelegate method didRegisterForRemoteNotificationsWithDeviceToken is called and the device token is sent to a local server application (node.js). The test itself creates an iOS 18.6 Simulator with xcrun simctl, builds such app and run the tests through through CLI with xcodebuild. Running this on my personal Macbook Pro M1 2021 goes well every time, so I wanted to bring it on Github Actions (arm64 macOS machines), in order to test the works on a open source library I'm building (hapns). Contacting Github support led me to test this on a macOS image running inside a VM inside a Veertu Anka container on my personal Macbook Pro, due to an VM architectural limit suspicion. The results were the same: iOS simulator isn't able to receive the device token. Not even didFailToRegisterForRemoteNotificationsWithError is called (tested through some network probes-requests that communicate to the server which checkpoints the process reached). So, as asked, I've setup a repro-case to be run in the VM and I've collected VM diagnostics ready to be tested and attached. Does anyone know if there is some unspecified (or specified but buried in the documentation) limit for this? Thanks. Github discussion link for further details, repro-case and so on: https://github.com/actions/runner-images/issues/12747

If you stucked for weeks trying to download your .p8 file, fail every time on every browser!! I finally download it using TOR browser

I'm not able to download my Private key since Yesterday and I get the following error message when I click on "Download" Auth Key can only be downloaded once. This auth key has already been downloaded. I revoked all my existing keys and created new ones and I get the same error message. I tried all the mentioned solutions on this forum and StackOverflow like using Safari,turning off VPNs,removing spaces from Key name, using my iPhone, using a Mac, incognito/private mode on Windows Microsoft Edge, clicking done then pressing download after, right clicking on download Linked File as...nothing seems to work

Hello everyone, I have been working on a macOS app that utilizes push notifications for the past year. Up until recently, everything was functioning correctly. However, now I'm experiencing issues where push notifications are either not being delivered at all or are experiencing significant delays, sometimes up to 10 minutes. Setting the priority header to 10 hasn't made any difference. I am currently using development push notifications, but the issue persists when switching to the production environment. I'm curious if anyone else has encountered similar problems. When checking the push console, it frequently reports that the device is offline, even though it's actually online ("discarded as device was offline"). Occasionally, notifications are delivered promptly, but this is becoming increasingly infrequent. This issue has been consistently reported by our testers, particularly after they updated to macOS Sonoma. Any insights or assistance you can provide would be greatly appreciated.

I created an APNs Auth Key in the Apple Developer portal and downloaded it successfully once. Later, due to some issues, I revoked that key. After that, I created a new APNs Auth Key. The download button appears, but when I click it, I get the message: "Auth Key can only be downloaded once. This auth key has already been downloaded." This is incorrect because: The key is newly created in my account. I have tried multiple browsers (Safari, Chrome), private/incognito mode, and even a different laptop. I have no other active APNs Auth Keys in my account. Without this .p8 file, I cannot configure push notifications for my iOS app (using Firebase Cloud Messaging). This is blocking my production release. Has anyone else experienced this? Is there a way to reset or force a fresh APNs Auth Key when this happens?

The iOS documentation shows notification actions buttons with the text center aligned: https://developer.apple.com/documentation/usernotifications/declaring-your-actionable-notification-types But there's no apparent way for an app to control this. The buttons are controlled and rendered by the system and the text is always left aligned. Is there some way to get the text center aligned?

We are in the process of transferring our app to a new Apple Developer Organization account. Our app uses the Apple Push Notification service (APNs) with a .p8 authentication key configured on our server to send push notifications. We would like to confirm: Once the app transfer is completed, will push notifications continue to work temporarily using the existing .p8 key on our server, until we generate and configure a new .p8 key under the new organization's account? Understanding this behavior is critical for us to ensure a smooth transition and avoid any disruption in push notification delivery for our users. Thank you for your guidance and support.

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.

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?

My first app