self.pushRegistry = [[PKPushRegistry alloc] initWithQueue:dispatch_get_main_queue()];
self.pushRegistry.delegate = self;
self.pushRegistry.desiredPushTypes = [NSSet setWithObject:PKPushTypeVoIP];
//处理接收到的VoIP推送
(void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void(^)(void))completion
then we send message from our server or from apple's cloud service: https://icloud.developer.apple.com/dashboard/notifications website services:
when app is in foreground,withCompletionHandler wil be called correctly,but when app is in background or has killed ,withCompletionHandler not be called!!!
the background fetch、voice over ip is checked in signing & capabilities tabs
why?why?why?why?why?why?why?why?why?
Notifications
RSS for tagLearn about the technical aspects of notification delivery on device, including notification types, priorities, and notification center management.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
AlarmKit custom sounds are universally broken in iOS 26.0 stable - instead of playing your custom sound, it plays a system error/timeout beep.
I've spent days investigating why custom sounds result in what sounds like an error beep (like when you cancel an operation or hit a timeout) instead of the actual audio file. I can now prove this is an Apple bug, not implementation error.
Evidence:
Test 1: My Implementation
Followed Apple's documentation exactly
Tried both bundle and Library/Sounds (as documented)
Result: System error beep (not my audio)
Test 2: Professional Apps
Tested ADHDAlarms (popular AlarmKit example by jacobsapps) https://github.com/jacobsapps/ADHDAlarms
Their airhorn.mp3 custom sound: same error beep (not an airhorn)
Their default sound: works perfectly
Test 3: Device Testing
Physical iPhone (iOS 26.0 - 23A341): broken
iOS Simulator: broken
Not device-specific
Files are found correctly, but the actual audio file is never played. Instead, you hear what sounds like a system error/cancellation tone.
What I've Eliminated
Not a Library/Sounds vs Bundle issue (both broken)
Not a file format issue (.mp3, .caf, .m4a all broken)
Not an implementation issue (professional apps broken too)
Not a device issue (simulator and device both broken)
Not a file size issue (5KB to 2MB all broken)
The Documentation Lie:
Apple's docs for AlertConfiguration.AlertSound.named(_:) state:
"Choose a file that's in your app's main bundle or the Library/Sounds folder"
https://developer.apple.com/documentation/activitykit/alertconfiguration/alertsound/named(_:)
Both locations are broken.
Tested on: iOS 26.0 (23A341), Xcode 26.0.1, Swift 6.2
Impact:
This affects any app trying to:
Provide personalized wake-up sounds
Use custom alarm tones
Create meditation/sleep apps
Differentiate from default iOS alarms
Current Status:
Multiple bug reports filed: FB19900024, FB18237648, FB19779004
Apple engineer claimed "fixed in latest beta" in August
Still broken in iOS 26.0 stable (September)
Workaround:
None that I know of. You must use .default sound.
For apps needing custom audio, play it with AVAudioPlayer after the alarm fires and user opens the app.
Question:
Has ANYONE gotten custom AlarmKit sounds working in iOS 26.0 stable? If so, plzzz help I'd be so grateful.
Im creating a basic app, needs push notification capability. I have created two profiles (development & distribution), selected my app in Identifiers and checked the PN box to enable it (no need for broadcast). I add the profile to Xcode and it says "Provisioning profile "New VP App Jan 2026" doesn't include the Push Notifications capability."
What am I missing?
Topic:
App & System Services
SubTopic:
Notifications
Hi team,
I am developing VOIP feature using PushKit and CallKit but CallKit is not show when app in background or terminate state, now in foreground state I can call reportNewIncomingCall from pushRegistry-didReceiveIncomingPushWith and it's work as expected but the problem is in background or terminate state it's not
my setup:
PushKit is configured
In Signing & Capabilities I add background modes (Remote notifications and Voice over IP)
In info.plist I add
<key>UIBackgroundModes</key>
<array>
<string>voip</string>
I'm not sure should I create new VOIP Certificate but now I can receive message notification normally.
Any help or suggestions would be greatly appreciated
Thank you
Push message on the lock-screen disappears in one specific instance.
In general the situation is as follows:
the application, upon starting up, sets the badge counter (i.e. notificationCenter.setBadgeCount(3))
the application is being sent to background
the screen is locked (it doesn't matter if it's turned on or not)
send a push message to the application and set the badge (in aps) to "0"
What happens:
the screen lights up (unless it's lit up already), the push is being displayed for a very short time and gets hidden.
Happens on iOS 18.1, 18.1.1, 18.2. If not setting badge in the aps keys it works correctly.
I've created a feedback report https://feedbackassistant.apple.com/feedback/16095572. I am able to reproduce the issue on a sample app 100% of the time :/
We are observing a significant increase in 410 "Unregistered/ExpiredToken" responses from APNs when sending push notifications after 20 July. According to documentation, this indicates that the device token is no longer valid for the specified topic. However, the sudden spike raises questions about whether there have been any recent updates or changes to APNs' token invalidation logic.
Could you please confirm:
Whether there have been any recent updates in APNs behavior related to 410 responses?
If there are best practices or recommendations for handling large volumes of token invalidations in order to detect uninstallations?
sending the following POST request:
---- HTTP REQUEST ----
POST https://appleid.apple.com/auth/token
Headers:
Content-Type: application/x-www-form-urlencoded
Body:
client_id=au.com.thejlrguy.businesschat&client_secret=eyJhbGciOiJFUzI1NiIsImtpZCI6IktLUDc4MkhGVTcifQ.eyJ...QeDn7ug&grant_type=client_credentials&scope=https%3A%2F%2Fappleid.apple.com
Getting the below error:
{"error":"invalid_client"}
The private key used to sign the JWT was created 24 hours ago.
I need to create a background notification that counts down time and uses buttons to add or subtract time. Currently, I'm developing in React Native and using Expo Go to develop my app.
I managed to display a simple notification, but I can't get it to work in real-time, so that when the time is up, it emits a sound indicating that the break is over.
How can I implement this feature?
My application now:
My goal:
I'm trying to rewrite a Swift code to Swift 6 language mode and am stuck with this problem. How do I safely pass the bestAttemptContent and contentHandler to the Task? This is from the UNNotificationServiceExtension subclass.
final class NotificationService: UNNotificationServiceExtension {
var contentHandler: ((UNNotificationContent) -> Void)?
var bestAttemptContent: UNMutableNotificationContent?
var customNotificationTask: Task<Void, Error>?
override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) {
self.contentHandler = contentHandler
bestAttemptContent = (request.content.mutableCopy() as? UNMutableNotificationContent)
guard let bestAttemptContent = bestAttemptContent else {
invokeContentHandler(with: request.content)
return
}
do {
let notificationModel = try PushNotificationUserInfo(data: request.content.userInfo)
guard let templatedImageUrl = notificationModel.templatedImageUrlString,
let imageUrl = imageUrl(from: templatedImageUrl) else {
invokeContentHandler(with: bestAttemptContent)
return
}
setupCustomNotificationTask(
imageUrl: imageUrl,
bestAttemptContent: bestAttemptContent,
contentHandler: contentHandler
)
} catch {
invokeContentHandler(with: bestAttemptContent)
}
}
// More code
private func downloadImageTask(
imageUrl: URL,
bestAttemptContent: UNMutableNotificationContent,
contentHandler: @escaping (UNNotificationContent) -> Void
) {
self.customNotificationTask = Task {
let (location, _) = try await URLSession.shared.download(from: imageUrl)
let desiredLocation = URL(fileURLWithPath: "\(location.path)\(imageUrl.lastPathComponent)")
try FileManager.default.moveItem(at: location, to: desiredLocation)
let attachment = try UNNotificationAttachment(identifier: imageUrl.absoluteString, url: desiredLocation, options: nil)
bestAttemptContent.attachments = [attachment]
contentHandler(bestAttemptContent)
}
}
}
I tried using the MainActor.run {}, but it just moved the error to that run function.
The UNNotificationRequest is not sendable, and I don't think I can make it so.
Wrap the setupCustomNotification in a Task will move the errors to the didReceive method.
It seems like the consuming keyword will help here, but it leads to a compilation error, even with the latest Xcode (16.2).
Any pointers?
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!
Hello Team,
We are currently experiencing an issue where some of our devices are not receiving push notifications. We are sending notifications via the Apple Push Notification portal (https://developer.apple.com/notifications/push-notifications-console/) using the following two requests. However, in both cases, the notifications are not being delivered to the devices.
Scenario 1 :
When we send a request with apns-push-type set to alert, we receive the following error.
Request :
curl -v
--header "authorization: bearer ${AUTHENTICATION_TOKEN}"
--header "apns-topic: com.testcompany.sampletest"
--header "apns-push-type: alert"
--header "apns-priority: 10"
--header "apns-expiration: 0"
--data '{"aps":{"alert":{"title":"Test Notification Title","subtitle":"Test Notification Sub Title","body":"Test Notification Body"}}}'
--http2 https://api.push.apple.com:443/3/device/*devicetoken*
Response:
{
"code": 400,
"message": "bad-request",
"reason": "The device token is inactive for the specified topic. There is no need to send further pushes to the same device token, unless your application retrieves the same device token.",
"requestUuid": "c4ae39b4-87e1-4269-a1e9-163f60ec0385"
}
Scenario 2 :
However, if we send the request with apns-push-type set to background, the request is processed successfully by APNs, but no notification is received on the device.
Request :
curl -v
--header "authorization: bearer ${AUTHENTICATION_TOKEN}"
--header "apns-topic: com.testcompany.sampletest"
--header "apns-push-type: background"
--header "apns-priority: 10"
--header "apns-expiration: 0"
--data '{"aps":{"alert":{"title":"Test Notification Title","subtitle":"Test Notification Sub Title","body":"Test Notification Body"}}}'
--http2 https://api.push.apple.com:443/3/device/*devicetoken*
Response:
Getting a message that The notification sent successfully but no notification is received on the device.
In both cases (with alert and background push types), the push notification does not reach the device.
Additionally, when we validated the device token using the APNs Device Token Validator, it appears to be valid and returns the following message.
"Device Token is valid for sending Alert & Background push-type notifications in the Production environment"
Affected Device:
macOS version : MacOS 15.3.1
Processor : Apple M1
Could you please assist me in resolving this issue?
Thanks
Dear Apple Engineer
Recently we found that our push delivery rate has decreased. On the website "https://icloud.developer.apple.com/dashboard/notifications/teams/43Y657P48S/app/com.taobao.fleamarket", we found that starting from January 8, 2025, "Discarded - Token Unregistered" showed an upward trend, from millions to tens of millions.
We have not found the reason, and hope you can help us.
Team ID: 43Y657P48S
Bundle ID: com.taobao.fleamarket
Here are some failed tokens, in "Device Token Validator" The query is valid, but the user cannot receive the message:
56025f656cc3aa701898037f59e8d0cb937263ff5585cd1cec9ae661dcc15b19
5fbbd1e604d3662d7583e9377676f8fa276005145278d6dea04b4fc85a7b070e
f0970602551f8d249d8f97960a74006ad78688b52fec6b0d19a585 207caff62e 9388fb40209c100afc2db728342f6fe86c7e34787a8fe4a92b73d2503c5286e0 a2819a4708462588b07452ed827d9afb03c343b586e70dcb67a9981f76295704 8949373cd43783fa3e23d38d55ee1fd72475b39f9c2d2fedca3ecb925b094240
Best Regards!
Facing issue while sending push notification through the application. The APNs certificate is valid.
Below is the error log.
System.AggregateException: One or more errors occurred. ---> PushSharp.Apple.ApnsNotificationException: Apns notification error: 'ConnectionError' ---> System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.EndSend(IAsyncResult asyncResult)
at System.Net.Sockets.NetworkStream.EndWrite(IAsyncResult asyncResult)
--- End of inner exception stack trace ---
at System.Net.Security._SslStream.EndWrite(IAsyncResult asyncResult)
at System.Net.Security.SslStream.EndWrite(IAsyncResult asyncResult)
at System.IO.Stream.<>c.b__53_1(Stream stream, IAsyncResult asyncResult)
at System.Threading.Tasks.TaskFactory1.FromAsyncTrimPromise1.Complete(TInstance thisRef, Func3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at PushSharp.Apple.ApnsConnection.<SendBatch>d__21.MoveNext() --- End of inner exception stack trace --- at PushSharp.Apple.ApnsServiceConnection.<Send>d__2.MoveNext() --- End of inner exception stack trace --- ---> (Inner Exception #0) PushSharp.Apple.ApnsNotificationException: Apns notification error: 'ConnectionError' ---> System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndSend(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndWrite(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.Security._SslStream.EndWrite(IAsyncResult asyncResult) at System.Net.Security.SslStream.EndWrite(IAsyncResult asyncResult) at System.IO.Stream.<>c.<BeginEndWriteAsync>b__53_1(Stream stream, IAsyncResult asyncResult) at System.Threading.Tasks.TaskFactory1.FromAsyncTrimPromise1.Complete(TInstance thisRef, Func3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at PushSharp.Apple.ApnsConnection.d__21.MoveNext()
--- End of inner exception stack trace ---
at PushSharp.Apple.ApnsServiceConnection.d__2.MoveNext()<---
Topic:
App & System Services
SubTopic:
Notifications
After updating to iOS 26 beta 1, I can't receive any push notifications from most applications.
I can receive notifications from like Calendar, which uses local & reserved notifications, but I can't receive any remote-based notifications.
Topic:
App & System Services
SubTopic:
Notifications
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
We operate a social network application, SportsYou with over 3 million monthly active users and are experiencing significant issues with push notification delivery through APNs.
We have a large number of users reporting they are not receiving push notifications. Our infrastructure uses AWS SNS integrated with APNs to deliver notifications. However, AWS CloudWatch consistently reports successful delivery (Success response), even though users confirm they never received the notifications.
Because we receive success responses from AWS SNS, our system does not attempt to recreate or refresh the device endpoints. This leaves us unable to detect or recover from these delivery failures automatically.
This issue is widespread and inconsistent. It affects users across multiple variables including different iOS versions, different device models, and different versions of our application. We cannot identify a clear pattern that would help us isolate the root cause.
With millions of active users, even a small percentage of delivery failures represents thousands of users experiencing a degraded service. This is significantly impacting user engagement and satisfaction.
We need guidance on how to properly diagnose this issue and ensure reliable notification delivery to our users. Specifically, we'd like to understand why we're receiving success responses when notifications aren't being delivered, and what steps we can take to detect and prevent these failures.
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
Question, if I am writing async code in the notification service extension, I understand it terminates after 30 seconds.
If I want to wait until these async methods finish before calling the content handler, I believe an option I have is to use dispatch groups. However I am open to other solutions if there are better options.
My question is, if I use dispatch groups, is there any issue in using the main queue here? Or does the main thread not make sense to use in the context of the NSE?
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
if (self.contentHandler) {
self.contentHandler(self.bestAttemptContent);
}
});
Or is it recommended to instead use a different queue in the NSE?
dispatch_queue_t nseQueue = dispatch_queue_create("com.blah.blah.nse.queue", DISPATCH_QUEUE_SERIAL);
dispatch_group_notify(group, dispatch_get_global_queue(QOS_CLASS_(SOMETHING), 0), ^{ ... });
OR am I over thinking this? :) Thanks ahead of time, relatively new to iOS so just looking to learn/understand better.
Topic:
App & System Services
SubTopic:
Notifications
Tags:
APNS
Extensions
Notification Center
User Notifications
Hi all,
We’re implementing in-app subscriptions in our iOS app using App Store Server Notifications V2 in the production environment.
Everything is generally working well — we receive notifications such as DID_CHANGE_RENEWAL_STATUS, CANCELLATION, etc., and we log all incoming notifications into our own database.
However, we've encountered a single case where the INITIAL_BUY notification was not received for a specific user.
Interestingly, we did receive the later notifications (DID_CHANGE_RENEWAL_STATUS and CANCELLATION) for that same user.
Here is our setup:
App Store Server Notifications V2
Notification endpoint is stable and functioning normally (receives and logs other notifications)
Notifications are reliably stored in our database
The issue occurred only once for one user
Environment: Production
We've already contacted Apple Developer Support, but were informed that this issue is out of scope for direct support, and were directed to the Developer Forums.
Our questions:
Under what conditions might the INITIAL_BUY notification fail to be sent or delivered?
Is there any known behavior or scenario where Apple may skip the INITIAL_BUY notification?
Any recommendations on how to further investigate or verify whether it was sent from Apple’s side?
We’ve confirmed that the notification never hit our server (no logs, no DB record), and our system was healthy at the time.
Any insight would be greatly appreciated. Thank you!
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.