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.

After porting code to Swift 6 (Xcode 16.4), I get a consistent crash (on simulator) when using UNUserNotificationServiceConnection It seems (searching on the web) that others have met the same issue. Is it a known Swift6 bug ? Or am I misusing UNUserNotification ? I do not have the crash when compiling on Xcode 26 ß5, which hints at an issue in Xcode 16.4. Crash log: Thread 10 Queue : com.apple.usernotifications.UNUserNotificationServiceConnection.call-out (serial) As far as I can tell, it seems error is when calling nonisolated func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) I had to declare non isolated to solve a compiler error. Main actor-isolated instance method 'userNotificationCenter(_:didReceive:withCompletionHandler:)' cannot be used to satisfy nonisolated requirement from protocol 'UNUserNotificationCenterDelegate' I was advised to: Add 'nonisolated' to 'userNotificationCenter(_:didReceive:withCompletionHandler:)' to make this instance method not isolated to the actor I filed a bug report: Aug 10, 2025 at 2:43 PM – FB19519575

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?

I have my app configured as a Driving Task app with the entitlement and provisioning profile correctly set up. I am also requesting the ".carPlay" notification authorization option and setting up the carplay notification category with the ".allowInCarPlay" category, both without error. When testing with the iPhone and carplay simulators the user notifications I send are appearing on the phone but not in carplay. When I check the notification settings with UNUserNotificationCenter.current().getNotificationSettings() I see that carplay is shown to be not supported ("carPlaySetting: NotSupported"). The CarPlay Developer Guide 2025-06-09 (which is the version currently referenced in the Apple docs) states that "Starting in iOS 18.4, notifications are also supported in CarPlay driving task apps". Has this discrepancy been addressed anywhere, or is this an open issue? My software versions: MacOS: Sequoia 15.6 XCode: 16.4 iPhone Simulator: iPhone 16 with iOS 18.6

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.

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.

I created an app. One if its functionalities is receive Remote Notification in the background, while app is monitoring Significant Location Changes (SLC). This functionality worked fine. I was receiving these notifications correctly. Sometimes instantly, sometime with small or large delay. And then I send the app for review. It was rejected with 3 remarks: The app or metadata includes information about third-party platforms that may not be relevant for App Store users, who are focused on experiences offered by the app itself (I wrote that app communication works both for iOS and Android.) The app declares support for audio in the UIBackgroundModes key in your Info.plist but we are unable to locate any features that require persistent audio. EULA (End User License Agreement) is missing for in-app purchases. After the rejection the app is no longer receiving these notifications. They are there, since the app receives them, when I open app, or significant location change is detected. It also works, when I run the app directly from Xcode (in debug mode), not from TestFlight nor in Sandbox. It seem to me like Apple somehow spoiled my background capabilities on purpose or accidentally. Is it possible? What can I do with it? Is it the case that I should just fix the review remarks and send the app back to review, and once the app passes it, it will work again? Or should I not count on it? Any suggestions? I asked Apple using: https://developer.apple.com/contact/topic/#!/topic/select but so far no response.

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?

When User restarted iOS device, after powering on iOS App is not able to get VoIP push notification. If user opens App, immediate VoIP push receiving. In Normal (App Kill or Background state) everything works as expected. Issue is when device is powered on and immediately( In 1-2 mins) try to call on device. We are using delegate to show Call to User public func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void)

Hi All, im working on a project to send a push notification in CarPlay. Current accepted by apple entitlements is driving. Are custom actions / buttons allowed/supported in CarPlay notifications?

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.

Background: The project was created in Xcode 5, then recreated in new Xcode. Before migration, push notifications worked without issues, after migration device token stopped being extracted. Problem: iOS app registers for push notifications, but didRegisterForRemoteNotificationsWithDeviceToken or didFailToRegisterForRemoteNotificationsWithError methods are not being called. Current situation: App is registered for push notifications (isRegisteredForRemoteNotifications = true) Notification permissions are granted Entitlements are configured correctly (aps-environment: development) Bundle ID: com.autoserviceonline.app Team: BUSINESSVISION COMPANY, TOO (NS3FSG45V7) But callback methods are not being called What I've already tried: Deleted and recreated all App IDs in Apple Developer Portal Cleared Xcode cache and derived data Created new APNs certificates and provisioning profiles Removed "ghost" certificate from Keychain Access Problem persists Additional information: Also noticed that Push Notifications Console opens non-existent project "BV.TestSwiftData" with Personal Team instead of current corporate App ID com.autoserviceonline.app. These issues might be related to project migration from old Xcode. Request: Why iOS doesn't call callback methods for device token, although registration was successful?

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

We are currently planning the development of an iOS healthcare application that will require the use of Critical Alerts. I understand that these notifications bypass Do Not Disturb and Silent mode, and therefore require special entitlement from Apple. We understand that Critical Alerts require a special entitlement from Apple. Could you please clarify: Do we need to request and obtain Apple’s approval for Critical Alerts before we begin development of the app? Or can we apply for this entitlement after we have a working build or prototype ready? We want to ensure compliance and streamline our development process, so any guidance on the appropriate timing for the entitlement request would be greatly appreciated.

I'm encountering an issue with our legacy Objective-C codebase that uses UIApplicationDelegate. Here are the steps to reproduce the issue: Uninstall the application from the device. Install and launch the application. As part of the launch event, the client requests notification permission. The permission prompt is still displayed, even though the client receives a remote notification token (which appears to be a cached one). I followed the same steps with a sample app built with Swift (SwiftUI), and this issue did not occur. In the Swift app, I consistently received a delegate<didRegisterForRemoteNotificationsWithDeviceToken> call after the user allowed the notification permission. Could you please provide some insights into why this might be happening with only our client?

Hello everyone, I'm implementing the "Push to Start" feature for Live Activities, and I've run into an issue where the activity seems to be processed by the system but never appears on the Lock Screen or in the Dynamic Island. I suspect there's a silent crash happening in my widget extension immediately after launch, but I'm unable to capture any logs or crash reports in the Xcode debugger. Here is the flow and all the relevant data: 1. The Process My app successfully requests a pushToStartToken using Activity<EJourneyLiveActivityAttributes>.pushToStartTokenUpdates The token is sent to our server. The server uses this token to send a "start" event APNs push notification. The device console logs (from liveactivitiesd) show that the push is received and the system is "Publishing event". Expected Result: The Live Activity UI appears on the device. Actual Result: Nothing appears. The UI is completely absent. 2. Device Console Logs Here are the logs from the device console, which indicate a successful receipt of the push: pushServer default 12:08:22.716353+0200 liveactivitiesd Received push event for com.wavepointer.ejourney.staging::pushToStart pushServer default 12:08:22.716818+0200 liveactivitiesd Reduced budget for com.wavepointer.ejourney.staging::pushToStart to: 7 pushServer default 12:08:22.723458+0200 liveactivitiesd Publishing event: timestamp: 2025-07-24 08:57:19 +0000; activityIdentifier: 53C3EE9D-623C-4F38-93AE-8BB807429DAA; eventType: start(...) 3. APNs Payload This is the exact payload being sent from our server: { "aps": { "event": "start", "timestamp": 1753347375, "attributes-type": "EJourneyLiveActivityAttributes", "attributes": { "journeyId": "test123453" }, "content-state": { "distanceInMeters": 1000, "depTime": 1752745104, "arrTime": 1752748704, "depStop": "Arth, Am See", "arrStop": "Oberarth, Bifang", "depZone": "571", "arrZone": "566", "co2Save": 5.0, "co2SavePerc": 44, "companyName": "WP Innovation", "countryCode": "CH", "categoryId": 5, "subcategoryId": 3, "stationStartAssoc": "Assoc1", "stationEndAssoc": "Assoc2" } } } 4. ActivityAttributes Struct To prevent decoding errors, I have made all properties in my ContentState optional and added a custom decoder. @available(iOS 16.1, *) struct EJourneyLiveActivityAttributes: ActivityAttributes, Hashable { public struct ContentState: Codable, Hashable { var distanceInMeters: Int = 0 var depTime: Int = 1752843769 var arrTime: Int = 1752843769 var depStop: String = "" var arrStop: String = "" var depZone: String = "" var arrZone: String = "" var co2Save: Double? var co2SavePerc: Int = 0 var companyName: String = "Test" var countryCode: String = "CH" var categoryId: Int = 3 var subcategoryId: Int = 4 var stationStartAssoc: String? var stationEndAssoc: String? } var journeyId: String? } What I've Tried I have carefully checked that my Codable struct matches the JSON payload. I've made all properties optional to avoid crashes from missing keys. I have tried attaching the Xcode debugger to the widget extension process (Debug -> Attach to Process...) before sending the push, but no logs, errors, or crash reports appear in the Xcode console. The process seems to terminate before it can log anything. My question is: What could cause the widget extension to fail so early that it doesn't even produce a crash log in the attached debugger? Are there other methods to debug this kind of silent failure? Any help would be greatly appreciated. Thank you!

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?

We're experiencing an issue with Apple Push Notification service where APNs continues to return 200 OK responses for device tokens belonging to uninstalled applications. Issue Details: When sending push notifications to device tokens, APNs returns 200 OK responses even for devices where our app was uninstalled more than a month ago Thanks in advanced for support