We are observing an weird behaviour where a user uninstalled the app back in February (more than a month ago) but APNs is still accepting push notifications are returning success responses. We know that using APNs response codes for uninstall tracking is not reliable and that Apple will use fuzzy schedule to invalidate tokens. However, showing successful responses for month+ old tokens seems a bit misleading and results in wasted token processing for both us and Apple. Could you please confirm that invalidation (or fuzzy schedule) could take more than months to invalidate tokens on the APNs side? Is that expected or is this a bug somewhere?

I’m using Appnotic from my server to send notifications for an emergency service, where it is critical that notifications are delivered immediately. My payload looks like this: "aps": { "alert": "Test alert", "sound": { "critical": 1, "name": "sound.wav", "volume": 0.5 }, "content-available": 1, "category": "alert" }, "topic": "com.fireservicerota.FSR-Primary-Alerting", "custom_payload": { "id": "11", "type": "alert", "incident_id": 23434, "incident_response_id": 2652343, "expiration_time": "2024-06-06T16:59:05+01:00" } } I already have the critical alert entitlement and background processing enabled. Everything seems fine when debugging, but I’m experiencing issues: • Some notifications never arrive • Around 60% of notifications arrive with noticeable delay Since this is an emergency app, delivery speed is crucial. What could be causing this inconsistency?

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!

Version: iOS 18.1 and later (works as expected on iOS 18.0 and earlier) Area: SpringBoard / Notification Center / App Icon Rendering Description: When changing the app's alternate icon using UIApplication.setAlternateIconName(_:completionHandler:), the icon is updated correctly on the Home Screen and App Switcher. However, in Notification Center, the old app icon is still shown for notifications, even after the change has completed. This issue only occurs on iOS 18.1 and later. In iOS 18.0 and earlier, Notification Center correctly reflects the updated icon. - Steps to reproduce: Create an iOS app with alternate app icons configured in the Info.plist. Use UIApplication.shared.setAlternateIconName("IconName") to change the icon at runtime. Send a notification. Pull down Notification Center and observe the icon shown beside the notification. - Expected Behavior: Notification Center should reflect the updated (alternate) app icon immediately after the change. - Actual Behavior: Notification Center continues to display the old (primary) app icon. The new icon appears correctly on the Home Screen and App Switcher. Restarting the device does cause Notification Center to update and reflect the correct icon, which suggests a cache or refresh issue in SpringBoard or Notification Center. - Notes: Issue introduced in iOS 18.1; not present in 18.0. Reproduces on both physical devices and simulators. Occurs with both scheduled local notifications and remote notifications. Restarting the device updates the Notification Center icon, but this is not a viable user-facing workaround.

Hello, I am writing this because the behavior of the App Store Server Notification that our server receives is problematic in the Sandbox environment. I have two questions in total. When purchasing a Free Trial subscription, after receiving the SUBSCRIBED / INITAL_BUY Notification, DID_RENEW should be sent when it expires, but DID_FAIL_TO_RENEW/GRACE_PERIOD is sent. The EXPIRE Notification is sent after the subscription expires or DID_CHANGE_RENEWAL_STATUS/AUTO_RENEW_DISABLED is sent, but it does not arrive. The first problem is that I recently heard that automatic payments after a free trial require the user's consent via email. Is this the reason? If so, I am curious about how I can test it in the Sandbox environment. Is the second problem a bug?

Only iOS devices stop receiving notifications after a few days of the app being installed. To resolve this, you need to reinstall the app again. I'm using Firebase to send messages.

I am developing a system to send VoIP notifications to terminals with APNs. I understand that the maximum JSON Payload for VoIP is 5kb. If I want to send VoIP notifications to 3000 terminals, I am considering sending 3000 requests in parallel from the system to the APNs, will the APNs guarantee that the notifications will be sent to each terminal without a significant time lag when receiving 3000 requests simultaneously?

Hi, We are using Firebase to configure APNs (Apple Push Notification Service) for sending push notifications. During local testing, the push notifications are received properly when the app is in the foreground or background. After TestFlight testing and passing review, we found that when the app is installed using the developer's Apple ID, push notifications are received correctly whether the app is in the foreground or background. However, when the app is provided to other testers (using non-developer Apple IDs), notifications are only received when the app is in the foreground, and they are not triggered when the app is in the background or inactive state. Request for Assistance: Why, after TestFlight testing and passing review, does the app receive push notifications properly in the background when installed using the developer's Apple ID, but on other testers' devices, notifications are not received when the app is in the background? Are there any differences in Apple ID types or device configurations (developer ID vs. regular tester ID) that could affect the behavior of push notifications in the background mode? Do we need to apply any additional settings or permissions, particularly for handling background push notifications? Are there any iOS version or device-specific limitations that could impact the proper delivery of background push notifications? Additional Information: The app is properly configured for APNs, and push notifications are being sent via Firebase. In the developer's Apple ID test environment, the app receives push notifications properly whether it is in the foreground or background. On other testers' devices, push notifications are only received when the app is in the foreground, and they are not received when the app is in the background. All test devices have been verified to have notification permissions enabled, and Firebase configuration is correct.

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.

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

Hi, am facing an issue related to voip push notifications getting delivered 1-2 hours after apns-expiration to 0 and apns-priority to 10. I had raised a similar post got a reply that it may be due to network delay. But network delay can cause the delivery of voip push to be delayed only by few seconds or minutes. But in our case voip push is getting delivered hours after the voip call was attempted. Steps to reproduce: Put our voip app in background and lock iPhone. As app is put in background, socket connections gets disconnected from server. Now if a caller makes call to this app, the call should be delivered through voip push. 2) Voip push should ideally be received even if app is in background and iPhone is locked. It is connected to a good wifi network. But it does not receive the voip push. 3) After 1-2 hours user unlocks iPhone and opens voip app. As soon as user opens app, the voip push is received and phone starts ringing.

Hello, I received emails regarding the change to the Certification Authority (CA) for Apple Push Notification service, however I missed the February 24th 2025 deadline. What should I do? Push notifications to apple devices is currently not working.

Good day We developed a simple swift code to make the device ringing when a certain type of notifications arrives from our backend. This is the code: let phoneNumber = CXHandle(type: .generic, value: (self.userInfoForPluginCall!["data"] as! [String:Any]) ["caller"] as! String) callUpdate.remoteHandle = phoneNumber let configuration = CXProviderConfiguration(localizedName: "Trec Conf") configuration.maximumCallGroups = 1 configuration.maximumCallsPerCallGroup = 1 configuration.supportsVideo = false configuration.supportedHandleTypes = [.generic] configuration.iconTemplateImageData = UIImage(named: "callkit-icon")?.pngData() let callProvider = CXProvider(configuration: configuration) callProvider.setDelegate(self, queue: nil) callProvider.reportNewIncomingCall(with: callUUID!, update: callUpdate, completion: {error in}) We are noticing some problems on the call screen: on certain devices (iOS 18.4RC) the normal call screen appears and the user can answer or decline the call, on other devices (iOS 18.3, especially with dynamic island) only a phone icon appears in the upper right corner and no possibility to answer or deny call. Any idea on why we are encountering that behavior? Thanks

Hi everyone, We're experiencing an issue with our Flutter app that uses PushKit, CallKit, and Janus for handling VoIP calls. Everything works fine when the app is in the foreground, but when the app is in the background or completely closed (terminated state), the behavior is inconsistent: Sometimes, incoming calls are received as expected. Other times, the app does nothing, and the call is not delivered at all. Upon checking the console logs, we noticed that our app is being canceled (terminated by the system), which seems to be the reason why calls are not coming through. This happens randomly, making it difficult to reproduce consistently. Additional Details: The app is configured to handle VoIP notifications correctly. We are using PushKit to wake up the app and trigger CallKit for the incoming call UI. When the app is active, calls are handled correctly via Janus WebRTC signaling. We have verified that background modes for VoIP are enabled in the Info.plist. We suspect that iOS may be aggressively killing the app in the background, preventing incoming call notifications from reaching it. Questions: Has anyone experienced similar behavior with PushKit + CallKit on recent iOS versions? Could iOS be terminating the app due to background execution policies? Are there recommended best practices to ensure reliable delivery of VoIP notifications when the app is closed? Any insights or suggestions would be greatly appreciated! Thanks! Addional Information: this is the cancellation information at console: Received incoming message on topic hiperme.app at priority 10 por omisión 17:10:18.462084-0300 dasd CANCELED: com.apple.pushLaunch.hiperme.app:E8BACD at priority 10

Hello, I'm from Microsoft team maintaining push notification api behind Teams platform. We are experiencing strange and short error spikes towards APNS that seem to mostly correlate worldwide. We checked the networking and push request code but could not find what could be causing this. These error spikes are all timeouts or connection resets (by remote host, ie. APNS servers) and seem to come and go randomly: Would it be possible to check this for outages or some other metrics on your side or investigate why would it happen? Since it's worldwide it seems unlikely it's something broken on our side. We are using the standard APNS http2 endpoint with modern support for all RFC features (so everything should work normally). Mind you, our api might be in a unique position because of the volume of notifications (in the billions per day).

I'm sending push notifications to a notification extension, and within the extension setting the threadIdentifier to be the same. But I'm observing inconsistent grouping behaviour, and behaviour that changes over time. The general iPhone settings are to display notifications as a Stack, and the app settings are to show on lock screen, notification center and banners and the notification grouping is set to by app (changing it to automatic doesn't affect the behaviour below). Pushes are displayed on the lock screen grouped together, then if the device is roused and the screen swiped down to reveal the notification center then they are still grouped. So far so good. If the iphone is active then the notifications appear at the top of the screen, one by one, but in this case if there is a swipe down to reveal the notification center then the notifications are not grouped when displayed, but shown individually. But then if one waits a few minutes and then displays the notification center for a 2nd time, sometimes now they will be grouped, but sometimes not. Why are they not (always) being displayed as grouped in the notification center?

I'm strugling about the way how to code notifications for my weather aplication. I use data from my server that receives weather changing values from my own weather station and want to notify user of my app when eg strong wind will blow or temperature go under eg 3℃ etc. The weather station has 8 sensors so there is sometimes a lot of data changing in particular minute that i set to parse data from server and notify user about it. But the notifications only works only when app is on and couple minutes after locking display. So please what could i use strategy for the app to works even when the app sleeps ?

I am trying to issue the "start" APNs push notification to start a live activity for my iOS app. The notification appears to send correctly, there is no error message, but the live activity never appears for any of my users (users are in TestFlight). In addition to issuing the APNs commands from my server, I have also tried using the CloudKit Push Notification Console to manually generate a "start" notification. It submits correctly but the live activity never starts. I have also checked the Console app to watch the device logs and see if iOS is rejecting/throttling the live activity but I don't see any activity related to the start message at all. Here are some details: App bundle ID: `com.penzu.moodmoji` APNs topic: `com.penzu.moodmoji.push-type.liveactivity` APNs push type: `liveactivity` Recent apns-id: `7b633309-b7fd-4163-b620-776efa04f315` APNs payload: { "aps": { "timestamp": 1742651625, "event": "start", "content-state": { "totalDays": 7, "currentDay": 2, "progress": 0.29, "status": "ACTIVE", "reportReady": false }, "attributes-type": "GoalActivityAttributes", "attributes": { "totalDays": 7, "currentDay": 2, "progress": 0.29, "status": "ACTIVE", "reportReady": false }, "alert": { "title": "It's day 2!", "body": "Don't forget to record every time you feel anxious today." } } } I can confirm that LiveActivities started by the iOS app with ActivityKit work correctly, and the app does appear to be receiving pushToStartTokenUpdates: struct GoalActivityAttributes: ActivityAttributes, Sendable { struct ContentState: Codable & Hashable, Sendable { let totalDays: Int let currentDay: Int let progress: Double let status: String let reportReady: Bool } let goal: SimpleGoal } for await nextStartToken in Activity<GoalActivityAttributes>.pushToStartTokenUpdates { // send nextStartToken to server... } The app I'm testing with is in TestFlight, using the production APNs environment.

There's plenty of articles out there about programatically grouping push notifications. However I have tried setting the thread-id in the push payload when sending a push, or setting the threadIdentifier for a received push in a notification service extension to be the same for several pushes. But if within the iPhone Settings / Notifications the user selects to display pushes as List and turns off Notification Grouping, then each notification resulting from the push appears on its own separately. Is there something other than thread-id/threadidentifier that is used to programmatically group them? If not then whats the point of these as grouping and display is actually under the control of user.

I have three apps with a very low user rate, so it's easier to compare. In all three apps, when I send a notification to APNs, over two-thirds receive a "Stored - Device Offline" status, but only one or two notifications are delivered afterward. No message has been sent after that. The total number of recipients is 89; 26 were delivered to the device, and 62 were stored in APNs. One was delivered from storage, and one was discarded. All app users are located in the same region, and mobile internet or Wi-Fi is available everywhere. I can't believe that so many iPhone users aren't getting connected to APNs to receive the stored message. Or are event not connected. Or are there any other reasons why a notification cant be transmitted. (User beahaviour, time of not using the app or something else?)