If there is a Notification Service Extension which has the com.apple.developer.usernotifications.filtering entitlement, then does/how having that entitlement affect the preconditions for the NSE to be delivered a push?
Specifically, if the app has not prompted for requestAuthorization() is it expected that the push will be delivered to the NSE or not?
Thank you
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
Hello, I am trying to utilize the Critical Messaging API to allow my user to message 1 or multiple pre registered contacts automatically.
An issue I am having with this in testing is that when the application attempts to fire off texts to the phone numbers the success rate changes from trial to trial, with no variable changing. Sometimes I can send a Critical Message to multiple phone numbers in rapid succession, sometimes the message is only sent to 1 contact, and sometimes I get no successes. Each failure always returns the MSCriticalMessaging.notSupported error.
The API documentation states, "The send(_:to:) method only works if the app is backgrounded, if it’s called from foreground the framework returns a MSCriticalMessagingError.notSupported error."
If my app is always backgrounded in these tests, what other issues may cause this notSupported error return, and why does the outcomes success rate vary?
The APNs Feedback Service domain “feedback.push.apple.com” was deprecated on March 31, 2021, and became unavailable after August 2025 due to domain name resolution failures.
Will this feedback service become available again in the future?
Also, is it possible to use the APNs Feedback Service with a domain different from “feedback.push.apple.com”?
If I run the following code in didFinishLaunchingWithOptions()
UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in
if granted {
DispatchQueue.main.async {
application.registerForRemoteNotifications()
}
}
}
Then the result is that didRegisterForRemoteNotificationsWithDeviceToken() gets called.
However if I change the code to be just:
DispatchQueue.main.async {
application.registerForRemoteNotifications()
}
Or as as its already running on main in this scenario, then just
application.registerForRemoteNotifications()
Then didRegisterForRemoteNotificationsWithDeviceToken() does NOT get called, but also neither does didFailToRegisterForRemoteNotificationsWithError().
Obtaining a push token is supposed to be independent of the user granting notifications permissions, so why am I not observing that behavior?
I only observe this behavior when running on hardware, when running on the simulator both forms of the code work.
Yet its nothing to do with my phone not being able to contact the Apple servers etc. - if I change the code back and forth back and forth between the two then if 100% works when using requestAuthorization() and 100% doesn't when not using it.
There's nothing additional or out of the ordinary with the code, its standard app delete template stuff.
Why isn't it getting a push token when requestAuthorization() isn't used?
(I've tried adding an async delay to calling registerForRemoteNotifications(), but it made no difference).
I’m using iOS 26 beta 9 on my iPhone 15 Plus. When I receive a call from a contact with multiple phone numbers, the call history does not clearly show which specific number was used to call me. Why? How to fix this issue?
Topic:
App & System Services
SubTopic:
Notifications
I am unable to connect to APNs sandbox push endpoint from our backend servers. It works fine when hitting the request from my local machine but it fails from the infra servers. Here are the complete curl details.
Endpoint: https://api.sandbox.push.apple.com:443 CURL request and response:
curl -v https://api.sandbox.push.apple.com:443
Trying 17.188.168.149:443...
Connected to api.sandbox.push.apple.com (17.188.168.149) port 443
ALPN: curl offers h2,http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
TLSv1.2 (OUT), TLS handshake, Client hello (1):
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.sandbox.push.apple.com:443
Closing connection
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.sandbox.push.apple.com:443
There are no issues with Production endpoint. Can someone help? Verified all certificates. Everything worked fine until 29th July but started failing since 30th July
Here is the PCAP file. Additionally, Here is the outbound public IP : 3.251.214.255
apple_push_sandbox_pcap.txt
I created new APNS key, when i clicked on download, this is the error am getting:
Download Failed
Auth Key can only be downloaded once. This auth key has already been downloaded.
I dont have any key before and i have not downloaded the key before, it just a new key, i just created.
Please this is affecting the release of our client app, and the client is having negative thought concern our service not knowing it from you guys.
I've added a Notification Service Extension as a target to my React Native iOS app following Apple's official documentation. After completing all the setup steps as outlined in the documentation, the notification titles remain unchanged - notifications are arriving without any modifications, suggesting the extension isn't functioning properly.Testing Details:
Sending notifications via Apple Push Notification Console
Tested on iPhone 16 Pro Max (physical device)
Tested on iPhone 15 Pro simulator
Both show the same issue - no title modifications
The extension appears to not be executing at all. Has anyone encountered similar issues with Notification Service Extensions in React Native projects, or can suggest troubleshooting steps to verify the extension is properly configured and running?
I've added a Notification Service Extension as a target to my React Native iOS app following Apple's official documentation. After completing all the setup steps as outlined in the documentation, the notification titles remain unchanged - notifications are arriving without any modifications, suggesting the extension isn't functioning properly.Testing Details:
Sending notifications via Apple Push Notification Console
Tested on iPhone 16 Pro Max (physical device)
Tested on iPhone 15 Pro simulator
Both show the same issue - no title modifications
The extension appears to not be executing at all.
Has anyone encountered similar issues with Notification Service Extensions in React Native projects, or can suggest troubleshooting steps to verify the extension is properly configured and running?
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?
Hello everyone,
I’m working with AlarmKit (iOS/iPadOS 26) and encountering a critical blocker. On the simulator, after adding NSAlarmKitUsageDescription to Info.plist, AlarmKit functions as expected—no entitlement issues. However, when building to a physical device, Xcode fails with:
“Provisioning profile … doesn’t include the com.apple.developer.alarmkit entitlement.”
The core issue: there is no AlarmKit capability visible under App ID settings or provisioning profiles in the Developer Portal. Thus, this entitlement cannot be enabled or included in a profile.
Steps taken so far:
Reviewed WWDC25 AlarmKit session and documentation.
Reviewed Apple Developer documentation on entitlements and provisioning.
Verified there's no AlarmKit toggle or capability in the Developer Portal (Certificates, Identifiers & Profiles > Identifiers).
Submitted multiple Feedback requests via Feedback Assistant, but received no technical resolution.
Questions:
Is there meant to be a separate AlarmKit entitlement (distinct from Critical Alerts)?
If so, when will the com.apple.developer.alarmkit entitlement option be available in the Developer Portal?
In the meantime, how can developers test AlarmKit-based features on physical devices?
Could an Apple Engineer advise on whether an internal entitlement workflow or workaround exists for testing?
Thank you in advance for any clarity anyone can provide. I'm stuck at a total impasse until this is resolved.
—John
Current Project Configuration Relevant Parts:
info.plist:
NSAlarmKitUsageDescription
Schedules system-level alarms that break through Do Not Disturb and Focus modes to ensure alarms trigger reliably.
UIBackgroundModes
audio
background-app-refresh
location
remote-notification
entitlements.plist
aps-environment
development
com.apple.developer.icloud-services
CloudKit
com.apple.developer.alarmkit
com.apple.developer.usernotifications.time-sensitive
Topic:
App & System Services
SubTopic:
Notifications
I am unable to connect to APNs sandbox push endpoint from our backend servers. It works fine when hitting the request from my local machine but it fails from the infra servers. Here are the complete curl details.
Endpoint: https://api.sandbox.push.apple.com:443
CURL request and response:
curl -v https://api.sandbox.push.apple.com:443
Trying 17.188.168.149:443...
Connected to api.sandbox.push.apple.com (17.188.168.149) port 443
ALPN: curl offers h2,http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
TLSv1.2 (OUT), TLS handshake, Client hello (1):
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.sandbox.push.apple.com:443
Closing connection
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.sandbox.push.apple.com:443
There are no issues with Production endpoint.
Can someone help? Verified all certificates. Everything worked fine until 29th July but started failing since 30th July
Hi there,
Thank you for the framework 🙏
if I use Alarm.Schedule.Relative with Alarm.Schedule.Relative.Time(hour: hour, minute: minute) and Alarm.Schedule.Relative.Recurrence.never it seems like there is some (odd?) limit where alarm will get scheduled to next day if too close?
For example, lets say the current time is 12:00 PM, if I schedule alarm for 12:02 PM, it will schedule it for next day, while if I do 12:05 PM it will work as expected.
Is that expected? If yes, what's the behavior and is that documented anywhere?
I would expect any alarm thats scheduled in the future to fire for the current day (maybe if it's only 1 minute it gets tricky).
One problem is also that even if the framework says an alarm is scheduled, I don't have access to the "next alarm date"? I wish I did as otherwise I have to compute it (by "guessing" the AlarmKit calculation) if I want to do anything with that date.
Honestly, sometimes I think I am just going crazy when the alarm doesn't fire, but there SEEMS to be some odd behavior around this?
(of course, feel free to correct me on anything - I could be missing documentation or not understanding something)
Topic:
App & System Services
SubTopic:
Notifications
An Application Group with Identifier 'group.com.aaa.aaa.onesignal' is not available. Please enter a different string.
How can I Fix this error? I need to add it in this format.
Topic:
App & System Services
SubTopic:
Notifications
Docs mention the following about the timestamp field returned by APNs:
"The time, represented in milliseconds since Epoch, at which APNs confirmed the token was no longer valid for the topic. This key is included only when the error in the :status field is 410."
We would like to clarify whether this timestamp is subject to the fuzzy schedule or whether it represent the accurate time of when APNs knew that the token became invalid?
We understand that using 410 for tracking purposes is off label. However we still would like to have the most accurate information in regards to when token became invalid. This will help us debug user issues better in cases when they re-install, uninstall, change permission settings, etc.
I am experiencing an issue with push notifications on my iOS application. The issue is as follows:
On Android devices, push notifications are received immediately without any problems.
On iOS devices, the behavior is inconsistent:
When the app is in the foreground, notifications are received immediately.
When the app is in the background or in recent apps with a significant delay of 5–10 hours, push notifications are not received at all.
This behavior creates a major challenge for us, as timely notifications are critical for our app’s functionality. We have already verified the following points on our side:
Push notification certificates and APNs setup are correct.
Payload and server configurations are valid, as notifications are working fine on Android.
No restrictions from the server-side, since Android users receive notifications instantly.
It seems the issue is specifically related to iOS devices or APNs delivery. Could you please help us identify the cause and provide guidance on how to resolve this?
When setting a custom sound in AlarmKit, the alarm only plays the audio file once. I can understand why push notifications would play a sound only once, but I don’t understand why alarms can only play the sound for less than 30 seconds. We’re already at beta 6, so I’m wondering if Apple still hasn’t fixed this or if they have no intention of fixing it.
Topic:
App & System Services
SubTopic:
Notifications
We are so interested in AlarmKit which is presented at WWDC25. While we planning our app using AlarmKit, We had a few questions come to mind and were hoping you could provide some clarity. Please excuse the rather long list of questions, as we don't currently have a device available to test these features ourselves.
System Actions Related
Is there a limit to the number of alarms that can be scheduled using AlarmKit?
Are alarms scheduled with AlarmKit persistent across device reboots?
When an alarm is dismissed (either by swiping or pressing the power button), can our app detect this action and execute code in response?
Can we control the behavior of the physical Lock Screen buttons when an AlarmKit alarm is active, for instance, to trigger a snooze action?
Does AlarmKit function correctly during Do Not Disturb or Low Power Mode?
What is the expected behavior when an alarm from our app (using AlarmKit) overlaps with an alarm from another app that also uses AlarmKit? Which one is going to get its priority?
Thank you for your help.
Sincerely
Topic:
App & System Services
SubTopic:
Notifications
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 am currently implementing VoIP push notifications in my iOS app using PushKit. On iOS 18, I am able to receive VoIP notifications successfully when the app is in the foreground. However, when the app is in the background or in a terminated (kill) state, the notifications do not arrive.
In earlier iOS versions, my existing implementation worked as expected across all app states. This issue seems to have started after testing on iOS 18, which appears to have introduced stricter permission or background execution requirements.
Questions:
Has iOS 18 introduced new permission requirements or entitlements for VoIP push notifications?
Do I need to explicitly request a new type of user permission for VoIP notifications?
Are there additional background modes, Info.plist keys, or PushKit changes required for VoIP to work in background and terminated states on iOS 18?
Additional Information:
. Foreground: Works fine, pushRegistry(_:didReceiveIncomingPushWith:for:completion:) is triggered.
. Background/Terminated: No call to the above delegate method.
. Using correct voip push type in the payload.
. PushKit is configured in AppDelegate.
. Background modes for "Voice over IP" and "Background Processing" are enabled.
. Using a real device with iOS 18 for testing (not simulator).
Any guidance or updated documentation references for handling VoIP pushes in iOS 18 would be greatly appreciated.