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?

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.

Since upgrading to Xcode 26 beta 4 and using the iOS 26 simulator for testing our app, we've stopped being able to receive device tokens for the simulator from the development APNS environment. The APNS environment is able to return meta device information (e.g. model, type, manufacturer) but there are no device tokens present. When running the same app using the iOS 18.5 simulator, we are able to register the device with the same APNS environment and receive a valid device token.

Hello, I’m reaching out to gather information regarding the upcoming changes to APNs certificates that are set to be implemented in the beta at the end of January 2025. Specifically, I would like to understand the following: What will be the practical impact of these changes on apes apis ? What actually needed to be done at trust store for this changes, and how will it affect our current setup? What steps do we need to take to update the certificates on our servers? it’s crucial for us to address these changes in advance and keep our customers informed. Thank you for your help!

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

Hello Team, We are working on a requirement where the business wants to track the delivery of push notifications on iOS devices. Specifically, they want to capture the moment when the device receives the notification and it appears as a badge in the Notification Center—regardless of whether the app is in the background or not—and then send that delivery status back to APNs. We have explored multiple approaches, but so far, we are only able to capture events when the user interacts with the notification banner. We would like to understand: Is it technically possible to send an event to APNs or another service upon receipt of the notification on the device without requiring user interaction? Any guidance or recommendations would be greatly appreciated.

We have an app in Swift that uses push notifications. It has a deployment target of iOS 15.0 I originally audited our app for iOS 26 by building it with Xcode 26 beta 3. At that point, all was well. Our implementation of application:didRegisterForRemoteNotificationsWithDeviceToken was called. But when rebuilding the app with beta 4, 5 and now 6, that function is no longer being called. I created a simple test case by creating a default iOS app project, then performing these additional steps: Set bundle ID to our app's ID Add the Push Notifications capability Add in application:didRegisterForRemoteNotificationsWithDeviceToken: with a print("HERE") just to set a breakpoint. Added the following code inside application:didFinishLaunchingWithOptions: along with setting a breakpoint on the registerForRemoteNotifications line: UNUserNotificationCenter.current().requestAuthorization(options: [.badge, .alert, .sound]) { granted, _ in DispatchQueue.main.async { UIApplication.shared.registerForRemoteNotifications() } } Building and running with Xcode 26 beta 6 (17A5305f) generates these two different outcomes based upon the OS running in the Simulator: iPhone 16 Pro simulator running iOS 18.4 - both breakpoints are reached iPhone 16 Pro simulator running iOS 26 - only the breakpoint on UIApplication.shared.registerForRemoteNotifications is reached. Assuming this is a bug in iOS 26. Or, is there something additional we now need to do to get push notifications working?

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

The following issue has occurred: Push notifications are not being received on certain devices. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving normal responses from APNs. Users have confirmed that notifications are enabled on their devices, and they report no network issues. This problem is occurring for multiple users.

I have a function in my app to detect if screens are added or removed, watching for notifications from NSApplication.didChangeScreenParametersNotification. I am seeing some strange behavior when the screen attached to a Mac mini is turned off, macOS will spit out hundreds of the didChangeScreenParametersNotification, all relating to a 'ghost' screen being added and then subsequently replaced with the original screen a second later. This cycle will go on for hours until the screen is turned back on again. I can confirm this also happens with the CoreGraphics equivalent, with flags .added and .removed being the only changes. I would imagine this creates immense churn for all apps watching for screen changes. I've tried debouncing the notifications but even with a delay of 10 seconds this is still being called hundreds of times while the computer is idle and the screen is off. One constant I can see is that the CGDisplayUnitNumber() for the 'ghost' display is always 0, while the logical unit number for the real screen is '1'. Is it safe to ignore screens with 0? I'm trying to find a reliable way to prevent heavy processing for 'false' screens. I'm afraid because this ghost screen has parameters so different to the actual screen, it's otherwise not possible to ignore it as it looks like a new screen. See example below: // Observe notification NotificationCenter.default.addObserver(self, selector: #selector(displaysDidChange), name: NSApplication.didChangeScreenParametersNotification, object: nil) // Function to update screens called from displaysDidChange func updateScreens() { let screens = NSScreen.screens for screen in screens { guard let screenDisplayID = screen.displayID() else { NSLog("Screen does not have a display ID: \(screen.localizedName)") continue } let screenIdentifier = "v\(CGDisplayVendorNumber(screenDisplayID)), m\(CGDisplayModelNumber(screenDisplayID)), sn\(CGDisplaySerialNumber(screenDisplayID)), u\(CGDisplayUnitNumber(screenDisplayID)), sz\(CGDisplayScreenSize(screenDisplayID))" } // -- Logic to determine if screen is new or already exists for window management -- NSLog("Found new screen display ID \(screenDisplayID) (\(screenIdentifier)): \(screen.localizedName)") } And the logging I'll get: Found new screen display ID 2 (v16652, m1219, sn16843009, u1, sz(1434.3529196346508, 806.823517294491)): Philips FTV Found new screen display ID 10586 (v1970170734, m1986622068, sn0, u0, sz(677.3333231608074, 380.9999942779541)):

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.

The app will be wake up from killed status by silent notification or not? This is a question for years, from my test. It will wake up. Here the wake up means it will call the "didFinishLaunchingWithOptions" method. But we can not see the app in the "recent apps" list after switching home-screen up. So any Apple dev can give me a detailed explain for this?

I am developing an application that uses NetworkExtension (Local PUSH function) And VoIP(APNs) PUSH. Nowadays, I found a problem on this app doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an APNs PUSH. My confimation result of my app and server log is below. 11:00 AM: my server(PBX) requests a VoIP(APNs) PUSH notification to the APNs. But my app does not receive the VoIP(APNs) PUSH. At this time, my app is running on LAN (Wi-Fi without internet connection), as a result, NetworkExtension was running. so I think this is normal behaviour. 14:55:11 PM: There is an incoming call from the my server(PBX) via local net, and NetworkExtension calls iOS API(API name is reportIncomingCall). However, iOS does not call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall. 14:55:11 PM: At almost the same time, iOS calls the delegate cdidReceiveIncomingPushWithPayload of VoIP PUSH. (instead of call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall?) And the content of this VoIP(APNs) PUSH was the incoming call at "11:00 AM". In other words, the VoIP(APNs) PUSH at 11:00 AM is stuck inside iOS, and at 14:55:11 PM, from NetworkExtension reports it. I feel there is a problem on iOS doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an VoIP(APNs) PUSH. Would you tell me Apple's opioion about this? If this is known problem, Please tell me about it.

Hello all 👋 We're developing an app for families with neurodivergent members (primarily autistic children) and have run into a critical reliability issue with silent push notifications that breaks core functionality. Our current implementation: When a caretaker updates the person's daily routine/schedule in our system, we send a silent push notification to the user's device. The app wakes, connects to our server, downloads the updated schedule, and creates/updates local notifications for upcoming activities. The problem: Because the app is rarely/never directly interacted with by the end user (the child doesn't open the app - caregivers configure it on their behalf), silent push notifications get progressively throttled and eventually stop being delivered entirely. This means schedule changes made by caregivers never reach the device, breaking the app's core value proposition. Uninstalling and reinstalling doesn't reset the throttling state Questions: Is there any way to reset or mitigate throttling for devices that legitimately need background updates but have low or no user interaction? This is an accessibility use case where the end user (child) doesn't interact with the app, but the app must reliably receive updates. Would switching to regular (visible) push notifications avoid this throttling even if the app is not interacted with? We already have Critical Alerts entitlement, but for regular updates we're worried that the "CRITICAL ALERT" banner will be too upsetting for the child. Is there any exception process for accessibility apps to change the way Critical Alerts are presented? For neurodivergent individuals, predictable routines are essential. When schedule updates don't reach their device, it can cause significant distress. This is a genuine accessibility need, not a "nice-to-have" feature. Any guidance from Apple engineers or developers who've solved similar challenges would be greatly appreciated. Thank you!

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?

PLATFORM AND VERSION: iOS Development environment: Other: .net MAUI with vscode Run-time configuration: iOS 18.1.1 DESCRIPTION OF PROBLEM APNS notifications of apns-push-type pushtotalk sometimes stop arriving after switching networks. STEPS TO REPRODUCE We have created a simple app which can be used to deminstrate this issue. When you launch the app it displays the APNS token which you can then use fromn the Apple Push Console to manually send it PTT push notifications. https://github.com/trampster/PttPushNotificationIssue On an iPhone SE (we havn't been able to reproduce on our iPhone 11) Start the APP to register for the APNS push notifications Turn off the WiFi wait for 5 seconds Attempt a push to the app manually using the Push Notifications Console (this should fail, which is fine) Turn on Cellular and wait for it to connect Attempt to push to the app manually using the Push Notifications Console -> This fails, and all attempts to send an pushtotalk push notifications fail until the we switch network again. Send a push while offline before connecting to the new network seems to make it happen more often but hard to tell for sure. The results of the failed push in the console look like this: Delivery LogLast updated: 30/01/25, 16:45:06 GMT+13 Refresh 30 Jan 2025, 16:45:03.661 GMT+13 received by APNS Server 30 Jan 2025, 16:45:03.662 GMT+13 discarded as device was offline The device is actually very much online. Switching networks again oftern makes things come right. But it doesn't seem to come right by itself. We can't respond to network changes and do anything as the whole point of using push-to-talk push notifications is to wake up the app when in the background to answer a call, this means we are not running and therefore cannot respond to network changes to try to work arround this issue.

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).

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 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.

Hello, When attempting to assign the UNNotificationResponse to a Published property on the main thread inside UNUserNotificationCenterDelegate's method func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse) async both Task { @MainActor in } and await MainActor.run are throwing a NSInternalInconsistencyException: 'Call must be made on main thread'. I thought both of them were essentially doing the same thing, i.e. call their closure on the main thread. So why is this exception thrown? Is my understanding of the MainActor still incorrect, or is this a bug? Thank you Note: Task { await MainActor.run { ... } } and DispatchQueue.main.async don't throw any exception.