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?
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
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
Is there a public method to know when an APNS has appeared on the screen?
wrapping up a very high end photogrammetry app, using the front facing camera and screen illumination-
incoming notifications completely throw off the math.
Ideally, it would be great to turn on Do Not Disturb for the short process, but we’d settle for just the detection of the notification banner.
also: extra credit - programattically adjusting Auto Dimming, and True Tone would be lovely too.
Our mobile app uses a specific platform for subscription management. At this time,, it's integration with Apple notifications is built around the Server-to-Server Notifications v1 and the traditional verifyReceipt endpoint. At this time, it does not support Server-to-Server Notifications v2, nor has any published documentation or resources on a custom integration path using v2.
Our app is built using Flutter and we handle purchases with the in_app_purchase plugin. However, due to the limitation on the system for subscription side, we need to connect to Apple’s legacy server-to-server subscription endpoints (StoreKit v1) to receive real-time notifications and validate receipts. Could you please provide information how to do it?
Topic:
App & System Services
SubTopic:
Notifications
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.
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
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
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.
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.
Problem Description
Location-based notifications added with UNLocationNotificationTrigger and CLCircularRegion do not fire consistently when the user enters the monitored region. Sometimes they work, sometimes they do not. In tests where the user physically enters the region and waits several days, the notification often never triggers.
What we’ve confirmed
Notification permission is granted
Location permission is set to “Always”
The notification request is successfully added (no error from UNUserNotificationCenter.add)
Pending notification requests are present when checked with getPendingNotificationRequests
CLLocationManager didEnterRegion / didExitRegion work when we monitor the same region via startMonitoring(for:)
UNLocationNotificationTrigger behavior is inconsistent and unreliable in our tests
Reproduction Steps
Launch the app and grant notification permission and “Always” location permission
Add a region notification (either by current GPS location or by selecting a point from MKLocalSearch)
Leave the monitored region
Later, physically return into the region
Expected: a notification is delivered when entering the region
Actual: the notification often does not appear, even after waiting days
Our Hypothesis: Coordinate System Mismatch in China
We suspect the issue may be related to coordinate systems in mainland China.
In China, Apple MapKit and MKLocalSearch use GCJ-02 (the “Mars” coordinate system required by local regulations).
Device GPS and CLCircularRegion / Core Location use WGS-84.
If an app supplies GCJ-02 coordinates to CLCircularRegion (e.g. from MapKit or search), the region center may be offset by hundreds of meters from the actual WGS-84 position. That could make the system’s “inside region” check fail, even when the user is physically inside the intended area.
Questions for Apple
Does CLCircularRegion (and therefore UNLocationNotificationTrigger) expect coordinates in WGS-84? If so, should apps in China convert GCJ-02 to WGS-84 before passing coordinates to CLCircularRegion?
Is there any official guidance or documentation for handling coordinate systems when using location-based notifications in mainland China?
Are there known limitations or special requirements for UNLocationNotificationTrigger in China (e.g. coordinate system, accuracy, or system behavior) that could explain intermittent or missing triggers?
I have converted a large part of the data, but only 5% of the data was successfully converted. The failed devicetoken shows "bad devicetoken" when accessing APNS. Here are examples of failed conversions devicetoken. Is there any official documentation for this part?
DeviceToken Orgin \xc2\xa1\xcb\x9cr\xc3\x81\xe2\x80\x9e\x01b\xc3\xbce1pf\t\xc2\xa7\xc3\x82v}\xc3\xa1\xc3\x9a:?\r\n\xc3\xa5\xc6\x92\xc3\xb7y\xc3\x9e\xe2\x80\x9c\xc3\x89r
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
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
I wanted to know if Apple ever supported displaying a red dot on notificationswith no indication number.
Topic:
App & System Services
SubTopic:
Notifications
I’m building a firefighter app that needs to automatically check in a firefighter when they arrive at the station and check them out when they leave — even if the app is killed. We need reliable enter/exit detection, low latency, and only one fixed location per user.
We’re evaluating Region Monitoring, which works in the killed state but may introduce delays and inconsistent accuracy. To ensure mission-critical reliability, we are considering the Location Push Service Extension, since it can fetch precise location on demand and wake the extension even when the app is terminated.
Before requesting the restricted entitlement, we need clarification on Apple’s expectations:
Is Region Monitoring recommended for this fixed-location use case?
Would Apple consider approving the Location Push Service Extension for a public-safety workflow?
What prerequisites do we need before submitting the entitlement request (Always permission, prototype, privacy disclosures, etc.)?
What details should be included in the justification form?
Our goal is to follow the most reliable and Apple-approved approach for firefighter check-in/out. Any guidance would be greatly appreciated.
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?
Having voice control enabled now puts three menu bar items. The blue icon it has always had, supplemented with an orange microphone and an orange dot next to control center. I know this orange icon is there to notify me that a third-party application is accessing the microphone, but this is a first-party system service that is always running. If another app starts accessing the microphone I won't know, since the orange icon is always there anyway. It's like a California prop 65 warning. Maybe it was a good idea in principal but with it being ubiquitous everyone just ignores it. Siri is also always accessing the microphone, but doesn't trigger this orange eyesore because it's a system service. Both Siri and voice control are always on in the background, are first-party system services that must be specifically enabled, and both have their own menu bar icon that can be removed if not wanted. This orange icon with voice control potentially introduces MORE risk by training me to ignore the orange icon. Please return to the pre-26.3 behaviour of using this orange icon for third-party apps and not first-party system services.
FB22036182 -- "Voice control causes extra menu bar icon"
Topic:
App & System Services
SubTopic:
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
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
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.