Hi Team,
We are building oru subscrption app and want to rely on server side purchase / subscription related notifications. We went through
https://developer.apple.com/documentation/appstoreservernotifications/enabling-app-store-server-notifications
We wanted to understand the reliability and latency for server side notifciations provided by Appstore.
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
Is there any information for developer about notification forwarding which is published in iOS 26.3? how to use it ?
Hey there my application allows users to have video calls with each other using Agora. I have successfully set up incoming call functionality on Android but on iOS I am struggling to get the call ui to appear when the app is not running/in background/locked.
To my knowledge this is because there is much stricter security on iOS which is limiting me from calling this. When i initially set it up it worked at first when the app was in the background but I think I was failing to report the call to call kit in time and now it's not working.
I'm not sure if I need access to this entitlement:
com.apple.developer.pushkit.unrestricted-voip
Which i believe is only for the big boys or if I make sure I'm reporting the call to call kit fast enough that I won't encounter this issue and it will consistently work in the background.
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.
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?
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
Discrepancy between App Store Server API `expiresDate` and iOS Settings subscription expiration date
I am developing an iOS app that uses App Store Server API (v2) for auto-renewable subscriptions.
I noticed a discrepancy between the expiration date returned by the API and the date displayed in iPhone Settings > Subscriptions:
App Store Server API expiresDate: 2025-09-12T12:10:25 (KST)
iOS Settings > Subscriptions: 2025-09-11 (one day earlier)
My understanding:
The API’s expiresDate is the precise UTC timestamp.
The Settings UI might display the "last full calendar day" for UX purposes.
Questions:
Is this behavior (UI showing one day earlier) an intentional Apple policy?
If so, is there any official documentation or guideline explaining this behavior?
Should developers always rely on the API’s expiresDate for subscription state management?
This discrepancy is confusing for both developers and end users, so any clarification or official reference would be greatly appreciated.
Topic:
App & System Services
SubTopic:
Notifications
Hi Apple team,
We’re shipping a Live Caller ID Lookup extension on iOS 18 and have a question about the automatic refresh of configuration/PIR parameters.
Questions
1. Is there any documented interval/TTL (min/max) for the system’s automatic refresh of /config and PIR parameters, or is it entirely opportunistic (battery/network/usage)? I can’t find a cadence in the IdentityLookup docs.
2. Does iOS honor server cache headers (e.g., Cache-Control/Expires) to influence when it re-fetches?
3. Which events also trigger a refresh (enable/disable in Settings, OS/app update, device reboot, token/epoch change)?
4. Are there rate limits or best-practice limits for calling refreshExtensionContext and refreshPIRParameters?
Topic:
App & System Services
SubTopic:
Notifications
Tags:
Extensions
SMS and Call Reporting
CallKit
I'm sending local push notifications and want to show specific content based on the id of any notification the user opens. I'm able to do this with no issues when the app is already running in the background using the code below.
final class AppDelegate: NSObject, UIApplicationDelegate, UNUserNotificationCenterDelegate {
let container = AppContainer()
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool {
let center = UNUserNotificationCenter.current()
center.delegate = self
return true
}
func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: () -> Void) {
container.notifications.handleResponse(response)
completionHandler()
}
}
However, the delegate never fires if the app was terminated before the user taps the notification. I'm looking for a way to fix this without switching my app lifecycle to UIKit.
This is a SwiftUI lifecycle app using UIApplicationDelegateAdaptor.
@main
struct MyApp: App {
@UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
I’m aware notification responses may be delivered via launchOptions on cold start, but I’m unsure how to bridge that cleanly into a SwiftUI lifecycle app without reverting to UIKit.
We have a question regarding iOS app configuration and the Remote notifications background mode.
During our testing, we observed:
*When enabling or disabling Signing & Capabilities > Background Modes > Remote notifications, the change does not take effect on devices that already have the app installed.
*The app continues to behave according to the old configuration.
*Only after uninstalling the app and reinstalling it from the App Store do the new settings take effect (for example, whether the app can be woken up by silent push).
*We also tested updating the app with a new version number (App Store upgrade flow), but the new settings still did not apply.
Our questions are:
1.Is there any way to make iOS re-read the updated Signing & Capabilities (Background Modes) settings without requiring a full uninstall/reinstall?
2.Is it expected behavior that even an App Store upgrade with a new version number will not apply these changes?
thanks!
Topic:
App & System Services
SubTopic:
Notifications
I’m getting calls from Pakistan every hour. I cant block them because it’s a different number every time. I have downloaded the new beta version of the upcoming software update and it allows you to set to ask a question before unknown callers ring through. It’s not working and my phone is constantly ringing. I can’t block unknown callers as I use my phone for work. How can I silence ringing from calls specifically from Pakistan Using the country code?
Topic:
App & System Services
SubTopic:
Notifications
In macOS, how can I use UnmutableNotificationContent notifications to prevent the main window from activating when clicking the notification?
code:
import Cocoa
import UserNotifications // Mandatory import for notification functionality
class ViewController: NSViewController {
override func viewDidLoad() {
super.viewDidLoad()
// Automatically request permissions and send a test notification when the view loads
sendLocalNotification()
}
/// Core method to send a local notification
func sendLocalNotification() {
let notificationCenter = UNUserNotificationCenter.current()
// 1. Request notification permissions (Mandatory step; user approval required)
notificationCenter.requestAuthorization(options: [.alert, .sound, .badge]) { [weak self] isGranted, error in
guard let self = self else { return }
// Handle permission request errors
if let error = error {
print("Permission request failed: \(error.localizedDescription)")
return
}
// Exit if user denies permission
if !isGranted {
print("User denied notification permissions; cannot send notifications")
return
}
// 2. Construct notification content using UNMutableNotificationContent
let notificationContent = UNMutableNotificationContent()
notificationContent.title = "Swift Notification Test" // Notification title
notificationContent.subtitle = "macOS Local Notification" // Optional subtitle
notificationContent.body = "This is a notification created with UNMutableNotificationContent" // Main content
notificationContent.sound = .default // Optional notification sound (set to nil for no sound)
notificationContent.badge = 1 // Optional app icon badge (set to nil for no badge)
// 3. Set trigger condition (here: "trigger after 3 seconds"; can also use time/calendar triggers)
let notificationTrigger = UNTimeIntervalNotificationTrigger(
timeInterval: 3, // Delay in seconds
repeats: false // Whether to repeat (false = one-time only)
)
// 4. Create a notification request (requires a unique ID for later cancellation if needed)
let notificationRequest = UNNotificationRequest(
identifier: "SwiftMacNotification_001", // Unique identifier
content: notificationContent,
trigger: notificationTrigger
)
// 5. Add the request to the notification center and wait for triggering
notificationCenter.add(notificationRequest) { error in
if let error = error {
print("Notification delivery failed: \(error.localizedDescription)")
} else {
print("Notification added to queue; will trigger in 3 seconds")
}
}
}
}
}
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’m building a standalone Apple Watch smart alarm app that should trigger alarms on the watch in response to Bluetooth or internet events.
This means the app operates in the background and attempts to trigger an alarm when such an event occurs. As far as I know, the appropriate API for this is WKExtendedRuntimeSession.notifyUserWithHaptic:repeatHandler.
However, I can’t seem to start an extended runtime session while the app is in the background. I’m getting the following error:
-[WKExtendedRuntimeSession _invalidationReasonAndDelegateCallbackErrorForError:outCallbackError:]:729:
WKExtendedRuntimeSession hit internal error.
Error Domain=com.apple.CarouselServices.SessionErrorDomain
Code=17 "startSession cannot be called on a scheduled session"
UserInfo={NSLocalizedDescription=startSession cannot be called on a scheduled session}
Calling notifyUserWithHaptic directly also similarly fails.
It seems notifyUserWithHaptic is intended to be scheduled during a foreground session to trigger at a later time, rather than being called ad hoc from a background context.
Is there any way to create a proper alarm view on the Apple Watch from a background execution context?
We have implemented Carplay in our voip based project and in this we have implemented Incoming call and chat notification feature for Carplay.
For Carplay we implemented siri.
Siri Object donated Successfully in Notification service Extension when notification didreceive method called.
Donation Code :-
func donateIncomingMessageIntent(sender: String, senderId: String, message: String, messageId: String, userInfo: [AnyHashable: Any],destination:String) {
// Create proper name components
clearAllinteraction()
var nameComponents = PersonNameComponents()
nameComponents.givenName = sender
//unknown
let senderPerson = INPerson(
personHandle: INPersonHandle(value: senderId, type: .unknown),
nameComponents: nameComponents,
displayName: sender,
image: nil,
contactIdentifier: senderId,
customIdentifier: "sender_\(senderId)"
)
let recipientPerson = INPerson(
personHandle: INPersonHandle(value: "me@example.com", type: .emailAddress),
nameComponents: nil,
displayName: "Me",
image: nil,
contactIdentifier: "me_id",
customIdentifier: "user_id"
)
let inMessage = INMessage(
identifier: messageId,
conversationIdentifier: "conversation_\(senderId)",
content: message,
dateSent: Date(),
sender: senderPerson,
recipients: [recipientPerson],
groupName: nil,
messageType: .text
)
let intent = INSearchForMessagesIntent(
recipients: [recipientPerson],
senders: [senderPerson],
searchTerms: [message],
attributes: .unread,
dateTime: nil,
identifiers: [messageId],
notificationIdentifiers: [messageId],
groupNames: ["Messages"]
)
let interaction = INInteraction(intent: intent, response: nil)
interaction.identifier = "message_\(messageId)"
interaction.direction = .incoming // Add direction
DispatchQueue.global(qos: .userInitiated).async {
interaction.donate { error in
if let error = error {
print("❌ Failed to donate INSearchForMessagesIntent: \(error.localizedDescription)")
} else {
print("✅ Donated INSearchForMessagesIntent successfully!")
let intentData: [String: Any] = [
"senderName": sender,
"senderId": senderId,
"message": message,
"messageId": messageId,
"timestamp": Date().timeIntervalSince1970,
"conversationId": "conversation_\(senderId)", // Add conversationId
"destination":destination
]
let defaults = UserDefaults(suiteName: "group.com.chatapp") // 🔁 Use your App Group ID
defaults?.removeObject(forKey: "lastCarPlayIntentData")
defaults?.set(intentData, forKey: "lastCarPlayIntentData")
defaults?.synchronize()
}
}
}
}
Here SenderID is like 3000@abc,2000@abc etc.
In siri ,When we handle INSearchForMessagesIntent at that time all data getting from Userdefaults because without Userdefaults INSearchForMessagesIntent value nil.
Even we enabled announcement using .allowAnnouncement.
We also tried to save same sender in contact Book because sometime siri search contact and not found then may be raise this type of issue.
So we need code level support for read incoming message in carplay when notification comes.
Thank you.
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.
Topic:
App & System Services
SubTopic:
Notifications
Tags:
APNS
CarPlay
Notification Center
User Notifications
When subscription renewing , can do purchase_date faster than notification_date quickly?
I received my app user purchase notification
this purchase date is 2025-08-31 06:42:54(UTC)
but notification date is 2025-08-30 22:45:01(UTC)
how can you do this?
I can't understand it please let me explain
Topic:
App & System Services
SubTopic:
Notifications
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.
Here are some questions we received and answers:
Q1: Is there a limit to the number of alarms that can be scheduled using AlarmKit?
There is no set number as a limit, but this does not mean you can schedule a limitless number of alarms. Depending on device state, available resources, etc., the device may impose a limit, and restrict an app trying to schedule too many alarms simultaneously.
When you hit a limit and not able to schedule more alarms, you will receive the maximumLimitReached error.
Q2: Will the scheduled alarms persist after system or app events that may terminate an app, for example, a reboot, force quit, or app crash?
Yes, all alarms are expected to persist regardless of app or device state changes, once they are successfully scheduled.
Q3: Will alarms work if scheduled by an app that is hidden, or requires a passcode or Touch ID/Face ID to launch?
Hidden or passcode required apps do not work with AlarmKit. Currently, any scheduled alarms by such apps will silently fail.
Q4: When an alarm is dismissed (either by swiping or pressing the power button), can an app detect this action and execute code in response? What about force closed apps?
When an alarm is dismissed, the stopIntent set in the AlarmConfiguration is called.
Any code in the perform method of this AppIntent would execute.
Q5: Is there a focus mode that AlarmKit cannot break through?
No. AlarmKit alarms can break through all focus modes.
Q6: What is the expected behavior when alarms from multiple apps overlap? Which one gets priority?
Which alarm would get activated when multiple alarms are scheduled for the same time is non-deterministic. There is no way to guarantee which app or which alarm will "win".
Q7: What do pressing the physical buttons do when an AlarmKit alarm is active?
Any physical button that causes a reaction from AlarmKit will stop the currently alerting alarm.
Q8: If there are multiple alarms active at one time, which ones do physical buttons interact with?
Pressing a physical button will dismiss all currently alerting alarms
Argun Tekant /
DTS Engineer /
Core Technologies
Change History:
2025-08-15: First posted
Topic:
App & System Services
SubTopic:
Notifications
We're trying to add simple notifications to our CarPlay integration that should open certain template when pressed, but the issue is that when pressing this notification on CarPlay screen nothing is invoked in the code (presumably didReceive should be invoked). All works fine with the same notification but pressed on the iPhone screen - didReceive is invoked properly. How should I handle the action when push notification is pressed on CarPlay screen?