Please find below a complete app example. It has a button, when you press it, a local notification is created. However, the UnNotificationCenter.delegate is called twice, and I can't understand why. I am trying to move my project from Objective-C to Swift, and my similar code there doesn't get called twice, so I'm confused. Can anybody shine a light on this? Pointers appreciated. App: @main struct NotifTestApp: App { init() { UNUserNotificationCenter.current().delegate = NotificationReceiveHandler.shared configureUserNotifications() } var body: some Scene { WindowGroup { ContentView() } } private func configureUserNotifications() { UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in if granted { print("Notification permission granted.") } else if let error = error { print("Error requesting notification permissions: \(error)") } } } } class NotificationReceiveHandler: NSObject, UNUserNotificationCenterDelegate { static let shared = NotificationReceiveHandler() //>> THIS IS CALLED TWICE WHEN I PRESS THE BUTTON func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) { NSLog(">>> Will present notification!") completionHandler([.sound]) } } ///THE UI struct ContentView: View { var body: some View { VStack { Text("👾") .imageScale(.large) .foregroundStyle(.tint) Text("Notification test!") Text("When i press the button, will present is called twice!!").font(.footnote) .padding(10) Button("Create Notification") { createNotification( message: "This is a test notification", header: "Test Notification", category: "TEST_CATEGORY", playSound: true, dictionary: nil, imageName: nil) } .padding() .background(Color.blue) .foregroundColor(.white) .cornerRadius(8) } .padding() } } #Preview { ContentView() } private func createNotification(message: String, header: String, category: String, playSound: Bool = true, dictionary: NSDictionary? = nil, imageName: String? = nil) { let content = UNMutableNotificationContent() content.title = header content.body = message content.categoryIdentifier = category content.badge = NSNumber(value: 0) if let imageName = imageName, let imageURL = Bundle.main.url(forResource: imageName, withExtension: "png") { do { let attachment = try UNNotificationAttachment(identifier: "image", url: imageURL, options: nil) content.attachments = [attachment] } catch { print("Error creating notification attachment: \(error)") } } content.sound = playSound ? UNNotificationSound(named: UNNotificationSoundName("event.aiff")) : nil if let infoDict = dictionary { content.userInfo = infoDict as! [AnyHashable: Any] } let request = UNNotificationRequest(identifier: UUID().uuidString, content: content, trigger: nil) UNUserNotificationCenter.current().add(request, withCompletionHandler: nil) }

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.

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?

If a server is sending a push to an app, then how can it know whether it should be sending the push using the Apple sandbox push server, or the production server? If the app is on the app store or testflight then it needs to be using the sandbox server, but if the app is being run via XCode interactively as devs are developing/testing then the push needs to be sent via the sandbox server. But the server itself has no idea if the app was installed via Testflight/app store/XCode/ or a development .ipa. So the server can't know how to send the push. The app has to send the push token to the server anyway, so the app could inform the server which environment it should be sent over. But then how can the app detect that itself? A naive answer is to use #ifdef DEBUG to detect this, but that is incorrect. Which environment a push should be sent over is not correlated with that. For example an app could be being run with a debug scheme or a release scheme, but in both cases if the app is installed/running via xcode then the push environment has to be the sandbox. So my question is, is there a way the app can detect which push environment a push should be sent over in order than it can instruct the server accordingly?

I have set up an iOS application with CarPlay scene using carplay-driving-tasks entitlement. And as per latest policy changes I'm able to get push notifications in the CarPlay screen. But unlike from phone scene, when I tap on a notification from CarPlay I don't get a trigger on didReceive method to intercept the payload of the notification that user tapped on. Is there any other ways or configuration needed to get this working? I just need to get the payload and present an Alert template within the CarPlay when user taps on a CarPlay notification and the app opens.

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?

Excited for AlarmKit! I have found two concerns that I cannot find answers for though. The volume of my alarms seems to be very quite relative to the full volume capability of the device. For example, if I turn the volume all the way up and play the audio file, the sound is very loud. However then, if I set the alarm using alarm kit with the same audio, the track played during the alerting phase is not that loud. I am afraid that it will not be loud enough in real life. Will there be future support to set the volume level of the alarm to maximum settings? When I press the volume buttons (with the app open) during an active alarm, the audio stops, but the alarm manager does not clear these events. The alarm manager does clear the alarm event if the alarm is stopped through a live activity.

I’m having an issue with Firebase Cloud Messaging (FCM) where direct messages sent via the FCM token work perfectly, but notifications from Firebase Messaging Campaigns don’t reach my iOS app. Here’s what I’ve tried and confirmed so far: Setup & What’s Working: Direct Messages via FCM Token: These are received by the app without any issues. Notification Permissions: All necessary permissions are granted on the device. APNs Authentication Key: This is configured in Firebase, and the Firebase Console shows the campaign status as “Completed,” but messages don’t appear on the target device. My Steps: Uploaded the APNs Authentication Key in Firebase: Opened Apple Developer Console > Certificates, Identifiers & Profiles > Keys > Registered a New Key > Checked APNs service. Downloaded the APNs Key and uploaded it to Firebase under Project Settings > Cloud Messaging. Firebase Console Campaign Setup: Notification title and body are configured. Target set to “All Users” (for testing purposes). Message settings: sound enabled, Apple badge enabled, badge count set to 1, expiration set to 4 weeks. Code Setup (relevant parts): Using Firebase for authentication and data storage with Firestore. Configured AppDelegate for Firebase, FCM, and APNs token registration. Implemented UNUserNotificationCenterDelegate methods to show notifications when the app is in the foreground. Observed Behavior: The Firebase Console indicates the campaign is “Completed,” but the messages are not received on the device. There are no errors in the Firebase Console or my Xcode logs when sending the campaign. My AppDelegate is correctly handling the APNs token and FCM token registration. Here’s My Code Setup in AppDelegate: class AppDelegate: NSObject, UIApplicationDelegate, MessagingDelegate, UNUserNotificationCenterDelegate { func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { FirebaseApp.configure() Messaging.messaging().delegate = self UNUserNotificationCenter.current().delegate = self UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .sound, .badge]) { granted, error in if granted { print("Notification permission granted") } } application.registerForRemoteNotifications() return true } func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { Messaging.messaging().apnsToken = deviceToken } func messaging(_ messaging: Messaging, didReceiveRegistrationToken fcmToken: String?) { print("FCM Token received: \\(String(describing: fcmToken))") } func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) { completionHandler([.alert, .badge, .sound]) } }

I've built an app that supports live activities, but when trying to build and deploy I'm getting the error: Provisioning profile "iOS Team Provisioning Profile doesn't include the com.apple.developer.live-activity entitlement." Looking in Xcode - under signing and provisions, there is no "Live Activity" option to select. Looking in the developer portal, similarly under Certificates, Identifiers & Profiles, there is no "Live Activity" option. I've added com.apple.developer.live-activity to my entitlements file for both my widget and my main app target, and added NSSupportsLiveActivities to my info.plist files. I'm building on Xcode Version 16.0 Any ideas on how to fix this? Super confused! Thanks in advance!

Howdy, I'm trying to figure out how to replicate the following behavior for our app: The system is able to ascertain that the Mac equivalent of some iOS app is installed locally, and it prevents notifications from being mirrored. However, I am unable to determine how this association is inferred. When I check our iOS app under this prefpane, the switch remains enabled and toggleable—we'd like to act like Slack here. My initial assumption is that an app group containing both the Mac and iOS apps can be used to create the association; however, I would like to confirm that this is indeed the case before doing so. I'm not terribly confident about this. Details: The bundle identifiers of both apps do not match. This also applies to Slack; its iOS app is com.tinyspeck.chatlyio while its Mac app is com.tinyspeck.slackmacgap. In our case, the iOS app's identifier is like com.company.app while the Mac app's identifier is com.company.app.desktop. Both apps are signed with certificates that have matching team identifiers. The com.apple.developer.team-identifier entitlement is present on the Mac app. The Mac app shares a keychain access group with the iOS app. The Mac app is not sandboxed. The Mac app is an Electron app. The Mac app does not use APNs. It sends notifications "locally". I currently only have the iOS app installed on my iPhone via TestFlight, if that matters. Notification mirroring does work, but we'd like to forcibly disable this by associating the apps together. To my knowledge, the iOS app makes use of both a UNNotificationServiceExtension and a UNNotificationContentExtension. The iOS app currently doesn't have an assigned category (at least in Xcode). The Mac app is currently miscategorized as a developer tool (LSApplicationCategoryType = "public.app-category.developer-tools";), but that should be fixed. (Redacted) bundle information for the Mac app: CFBundleDisplayName = App; CFBundleExecutable = "App Desktop"; CFBundleName = App; Note that our CFBundleExecutable differs from the bundle's display name/name because we're currently migrating our users to a new version of the app that they'd likely want to live alongside the new one. The filename of the bundle itself is, similarly, App Desktop.app. For the iOS app, to my knowledge, the CFBundleName and CFBundleDisplayName are App.

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?

Apple Push Notification service server certificate update https://developer.apple.com/news/?id=09za8wzy All developers using APNs will need to update their application’s Trust Store to include the new server certificate What exactly should developers do? Please tell me the specific method. Please make sure that both old and new server certificates are included in the Trust Store before the cut-off date for each of your application servers that connect to sandbox and production. How do I make sure that both the old and new server certificates are in the Trust Store? Thank you for your understanding.

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.

Hi, since a while I constantly receive the warning above and there is nothing to find on my Mac (Air M2) nor by searching the web. MacOS 15.1 Anybody an idea what this app/service is all about?

I see the log in my server and they told that PTT notification sent successful but bellow function not call from my app. Could you give me any suggest? func incomingPushResult(channelManager: PTChannelManager, channelUUID: UUID, pushPayload: [String: Any]) -> PTPushResult

Been one week and still on requested image playground image playground will not work says I’m still requested access

When using iCloud account with push in Apple mail app. The badge number of unread email is not syncing across devices. If I read an email on my iPhone my iPad mail app badge won’t update until I click into the app and wait for the update. Is there any fix of this?

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.

On December 6, 2024, I received the following email. Does this mean that there is something that needs to be done on the app side or on the Firebase side? Currently, in our project, we are using Firebase to set up push notifications. If anyone knows how to deal with this or has taken any action, could you tell me what specific steps you took? Action Required: Apple Push Notification Service Server Certificate Update As we announced in October, the Certification Authority (CA) for Apple Push Notification service (APNs) is changing. APNs will update the server certificates in sandbox on January 20, 2025, and in production on February 24, 2025. To continue using APNs without interruption, you’ll need to update your application’s Trust Store to include the new server certificate: SHA-2 Root : USERTrust RSA Certification Authority certificate. To ensure a smooth transition and avoid push notification delivery failures, please make sure that both old and new server certificates are included in the Trust Store before the cut-off date for each of your application servers that connect to sandbox and production. At this time, you don’t need to update the APNs SSL provider certificates issued to you by Apple.

Notification coordination between iOS and watchOS is not working properly watchOS and iOS try to coordinate between phone and watch notifications. The concept here is that if there is a main app and a companion app, they could both be sending a notification, then the notification would alert on both, which is a deviation from how notification mirroring is handled if there is an iOS app but no watch app. The watch waits for the iOS notification to fire so they can determine if this is the same notification that needs to be deduped, displayed on one device but not the other, or separate notifications to be displayed both. If there is no notification on the phone, the watch will timeout after 13 seconds and alert anyway. If you have an iOS companion app, the best solution to this is to send the same notification on both devices simultaneously, and ensuring the UNNotificationRequest.identifier matches on both notifications. This will let the systems determine how to handle the notification correctly and quickly, and the notification will alert right away. https://developer.apple.com/forums/thread/765669 According to the above article, "when a notification arrives on watchOS alone first, it coordinates with iOS," but in reality, it doesn't work properly. Detailed process of this phenomenon watchOS receives a notification. On watchOS, the notification is not immediately shown to the user. iOS receives a notification with the same UNNotificationRequest.identifier as in (1). The notification in (3) does not appear on either iOS or watchOS. However, the notification from (3) does appear in iOS Notification Center. Thirteen seconds after watchOS received the notification, the notification from (1) is shown to the user on watchOS. In the end, the iOS and watchOS notifications are not consolidated and each remains in its respective notification center. Up to (3) there are no issues. Starting with (4), both iOS and watchOS exhibit a lot of odd behavior. This phenomenon occurs with both local notifications and push notifications. When iOS receives the notification first, there is no problem. The notification for watch received later is processed appropriately, and the watchOS notification is not additionally displayed to the user. Expected proper process Same as above. Same as above. Same as above. The notification in (1) is integrated into the notification in (3). The notification in (3) is alerted to the user immediately. 2 sample projects to reproduce Only the main code is attached. Sample project1: local notifications Swift code for local notification app (iOS, watchOS) - App.swift.txt Sample project2: push notifications This sample project is implemented using Firebase Functions and Firebase Cloud Messaging. Swift code push notification app (iOS, watchOS) - App.swift.txt Server side JavaScript code for FirebaseFunction - index.js.txt Tested devices and OS This phenomenon occurred in both of the following patterns. Pattern 1 Xcode 26.0 iPhone 16 (iOS 26.0) Apple Watch series 10 (watchOS 26.0) Pattern 2 Xcode 16.4 iPhone 11 (iOS 18.6) Apple Watch SE 2nd gen (watchOS 11.6) Question Is this phenomenon a bug? Or is my understanding or implementation incorrect? Feedback Assistant number FB20339772