iOS has a feature that suppresses or limits the display of push notifications when multiple notifications are sent in quick succession (often referred to as rate limiting or filtering). Specifically, how many notifications within what timeframe might trigger such suppression?

Hello, We are currently facing a persistent issue where Apple Push Notifications (APNs) are no longer being delivered to devices. This is not an intermittent problem — push notifications have completely stopped working. We are using PushSharp.Apple (Version 4.0.10.0) to send the notifications. Current Behavior (Failing): Every notification request appears to be processed successfully from the server side. However, the APNs client receives a 0-byte response, and the server closes the connection. Devices do not receive the notifications at all. Logs from Current (Failing) State: APNS-Client[1]: Connected (Batch ID=1) APNS-Client[1]: Sent Batch, waiting for possible response... APNS-Client[1]: Received 0 bytes response... APNS-Client[1]: Server Closed Connection... APNS-Client[1]: Disconnected (Batch ID=1) For Reference – Successful Log From Earlier (When Notifications Worked): APNS-Client[1]: Connected (Batch ID=1) APNS-Client[1]: Sent Batch, waiting for possible response... APNS-Client[1]: Received -1 bytes response... Push Notification Successfully Sent to Device Any help, suggestions, or experience with similar issues would be greatly appreciated. Thanks!!!

Can I using AudioServicesPlaySystemSound for play sound os system on NotificationService?

PLATFORM AND VERSION: iOS Development environment: Other: .net MAUI with vscode Run-time configuration: iOS 18.1.1 DESCRIPTION OF PROBLEM APNS notifications of apns-push-type pushtotalk sometimes stop arriving after switching networks. STEPS TO REPRODUCE We have created a simple app which can be used to deminstrate this issue. When you launch the app it displays the APNS token which you can then use fromn the Apple Push Console to manually send it PTT push notifications. https://github.com/trampster/PttPushNotificationIssue On an iPhone SE (we havn't been able to reproduce on our iPhone 11) Start the APP to register for the APNS push notifications Turn off the WiFi wait for 5 seconds Attempt a push to the app manually using the Push Notifications Console (this should fail, which is fine) Turn on Cellular and wait for it to connect Attempt to push to the app manually using the Push Notifications Console -> This fails, and all attempts to send an pushtotalk push notifications fail until the we switch network again. Send a push while offline before connecting to the new network seems to make it happen more often but hard to tell for sure. The results of the failed push in the console look like this: Delivery LogLast updated: 30/01/25, 16:45:06 GMT+13 Refresh 30 Jan 2025, 16:45:03.661 GMT+13 received by APNS Server 30 Jan 2025, 16:45:03.662 GMT+13 discarded as device was offline The device is actually very much online. Switching networks again oftern makes things come right. But it doesn't seem to come right by itself. We can't respond to network changes and do anything as the whole point of using push-to-talk push notifications is to wake up the app when in the background to answer a call, this means we are not running and therefore cannot respond to network changes to try to work arround this issue.

Dear Apple Team, I hope this message finds you well. I wanted to share a playful and innovative idea that could enhance the iPhone experience—particularly when viewing content in full-screen mode through apps like Apple TV or YouTube. Feature Concept: Hands-Free Dismissal of Notifications When the iPhone is in landscape mode, incoming notifications can interrupt the viewing experience. While Focus Mode and swipe gestures help, I thought of a more intuitive and hands-free interaction: using a light puff of air directed toward the screen to dismiss a notification. This interaction could use the microphone or other onboard sensors to detect a brief burst of air, providing a fun and natural way to maintain immersion without touching the device. If this isn’t feasible with current hardware, here are a few alternative concepts that align with the same goal: Blink to Dismiss: Using Face ID sensors to detect a quick blink as a hands-free gesture. Shake to Dismiss: A gentle shake gesture when holding the iPhone in one hand. Gaze-Based Dismissal: Notifications automatically disappear after a brief moment of eye contact. These ideas could offer both accessibility benefits and a touch of delight—making the iPhone feel even more magical and responsive. Thank you for your time and for considering this suggestion! Warm regards, Badhan Baidya

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).

Hello, I am working on a project that involves using external device to connect over BLE with users iPhone. I would like to be able to notify users on our device about eg. incoming calls, messages etc. I have been succesfull in using ANCS to achieve that but I am a little worried around consistency of this solution, especially taking into account following line from documentation: Due to the nature of iOS, the ANCS is not guaranteed to always be present. As a result, the NC should look for and subscribe to the Service Changed characteristic of the GATT service in order to monitor for the potential publishing and unpublishing of the ANCS at any time. I have not been able (yet?) to find or identify circumstances when ANCS would not be avilable or would be "removed in runtime", hence would it be possible to request some guidance and clarification on the conditions when ANCS can be unavailable or removed? Thank you!

Hello, I am encountering an issue with maintaining socket connections in iOS applications that need to remain active while in background mode. I am developing an application that requires maintaining an active socket connection in the background to receive real-time data. However, I've noticed that the socket connection is terminated as soon as the app enters background mode, which affects the intended functionality of my app. I understand that there are restrictions on background activities in iOS to preserve battery life and system resources. However, I would like to know what approach Apple recommends for handling this type of requirement. Are there specific APIs or configurations I should consider to ensure the socket remains active in the background? I would greatly appreciate any guidance or resources you could provide. I am eager to ensure that my app complies with Apple's guidelines and delivers the best possible experience for users.

The app will be wake up from killed status by silent notification or not? This is a question for years, from my test. It will wake up. Here the wake up means it will call the "didFinishLaunchingWithOptions" method. But we can not see the app in the "recent apps" list after switching home-screen up. So any Apple dev can give me a detailed explain for this?

I'm facing an issue delivering VoIP push notifications to user devices. It's pretty random, sometimes notifications are delivered and sometimes not. I've had a call with the user to understand and narrow down the issue, including testing delivery of pushes to their device token via Push Notification Console as described here: https://developer.apple.com/documentation/usernotifications/testing-notifications-using-the-push-notification-console#4181180. I asked a user to use Wi-Fi first and tried delivering around 10 pushes via console and 2 of them were lost while the rest was delivered. I asked a user to use cellular and tried delivering also around 10 pushes and most of them were lost and only few of them were delivered. Production environment was used to deliver pushes hence I cannot see delivery log and so I have no visibility over a reason why push wasn't delivered. I wanted to file a code-level support ticket to get help however I need to supply a sample xcode project which in this particular case doesn't make any sense as I'm using Apple's Push Notification Console tool and it delivers pushes in some cases while doesn't deliver it in other cases. I'm pretty familiar with all potential reasons why push might not be shown on device, including app early crashes, not reporting a call to CallKit etc. => although you never know, I'm pretty sure it's not our case. How can I get support on investigating specific user device token delivery issues like in the case I described above? I have device token and push console records but it's not clear how to get support on that. Thank you!

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

Hey everyone! I'm trying to develop an app that would need to send periodic notifications (every 20 minutes, for instance) to the user even when the app is not running (but only when the phone is being used). I've been reading through the prior comments and all about not being able to have a timer run in the background in the way I need it to, but I wanted to ask if there's any way around this, or is there truly no way? If there is no way to do this, I was just now considering another workaround, where I could try getting the time they open their phone, and from there, I schedule local notification for every 20 minutes or so for the entire day, and they keep sending until the phone is turned off, when the rest of the scheduled local notifications are cancelled. Is this possible? I would also appreciate any other suggests/workarounds for this. Happy to provide any additional details needed! Thanks!

We provide users with an iOS app that sends VoIP notifications. However, we received issue from users that "VoIP notifications were not sent." So we conducted an investigation on-site and sent VoIP notifications more than 10 times to about 20 devices. We confirmed that most of the notifications arrived, but there were also times when the notifications were not sent. We would like to know if the VoIP notifications were really delivered to the devices that did not receive the notifications. If this phenomenon is a network problem, we would like to consult with the network company. We have attached the log of when we checked and the VoIP notification was not received. logs [2024-09-12 11:50:02] 'ApnsId' => '22541A6E-355E-73D6-D28F-D1F8E340E540' 'StatusCode' => 200 [2024-09-12 11:50:02] 'ApnsId' => '22541A6E-355E-73D6-D28F-D1F8E340E540' 'StatusCode' => 200 [2024-09-12 11:50:02] 'ApnsId' => '2984C9F3-CC81-9080-7B54-EF53D2E77D68' 'StatusCode' => 200 [2024-09-12 12:43:01] 'ApnsId' => 'A936595B-36F7-07C2-CFB7-3276C4BE8FC8' 'StatusCode' => 200 [2024-09-12 12:43:01] 'ApnsId' => '0C633C08-25B0-6FE2-2087-DD66C1C01532' 'StatusCode' => 200 According to these, the status code is 200. We would like to know if the VoIP notifications in the logs shown above were received by the iPhone device we tested.

System Information: iPhone 13, iOS 17.6.1 Steps to reproduce: Open my app, causing it to register for an APNS token Kill my app to make sure it is not in the foreground Send a push notification with a payload similar to this: {"aps":{"alert":{"title":"My App Name","body":"10:24am 🚀🚀🚀"}},"price":19,"clock":175846989,"time":1731001868.379526} And the following attributes: Expiry: (Date that is 7 days from now) Type: Alert Priority: High (10) Payload Size: 141 bytes The notification appears in the Notification Center, as expected Turn on Airplane Mode (WiFi=off) Wait between 60 seconds - 8 hours (varies) Send the same notification payload/attributes again Wait between 60 seconds - 8 hours (varies) Turn on WiFi Wait 1-30 minutes (varies) Expected behavior: The notification appears in the Notification Center Actual behavior: Push notifications from other apps immediately appear in the Notification Center Roughly 30% of the time: The push notification(s) from my app never arrive, even after waiting 30 minutes Roughly 70% of the time: The notification appears in the notification center, and everything works fine Thoughts: Expiry must be set correctly because I've seen my notifications get queued and then delivered (correctly) in the CloudKit Push Notification tool. Identical notifications (payload, APNS headers, etc.) are also sent to other devices at the same time. They receive the notifications just fine. It must not be my iPhone's notification Settings, because notifications appear correctly when online I've tried restarting the iPhone, it did not fix this issue So it seems it must be an unexpected behavior in APNS or something broken with my specific phone? Not sure what else I could possibly do to make sure the notifications arrive. This breaks the entire experience of my app. I need to be able to notify users of incoming messages so they do not miss them.

We would like to better understand the discrepancy between a Push To Start and the subsequent Updates where I see a number of recipients drop greatly. Our assumption is that this is a result of the end user not clicking the "Allow" prompt when a push to start widget is shown on the screen for the first time, but we currently do not have a way to listen to the user's choice when prompted. Is there any way of tapping into this, to determine if this is in fact where the variance is coming from, or if there is actually just a problem with the request to retrieve the update token from our end?

Hi After uploading a problematic version of our app to TestFlight my iphone does not get push notification anymore for our app. Other users are not affected. I deleted the app and installed the version from the appstore and still i do not get push notifications to the app. anyone that installed the version on testflight can't get push notification even if they went back to the original version from the app store. also tried to shutdown / startup the phone... no change. Any idea what went wrong and how to fix it?

I received the email from Apple: “Action Required: Apple Push Notification Service Server Certificate Update”. I'm not quite clear on what exactly I need to do. In my case, I have my own APN service on a DigitalOcean server and I have both .pem and .p12 certificate there. Can anyone help me?

Hi, Regarding the announcement about the Apple Push Notification Service (APNs) Server Certificate Update, I wanted to clarify whether it will impact my app’s push notification setup. I use Firebase Cloud Messaging (FCM) to send push notifications to iOS devices, and in my Firebase project settings, I have configured an APNs Authentication Key under the Apple app configuration tab (Firebase Console > Project Settings > Cloud Messaging > iOS app configuration). The authentication key I am using was generated from Apple Developer > Certificates, Identifiers & Profiles > Keys. Since I am using this authentication method instead of APNs certificates, are there any changes I need to be aware of due to the APNs server certificate update, and do I need to update anything in my current configuration to ensure push notifications continue to work? Thanks in advance!

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

Hi there, We’re using APNs Push delivery metrics, which provide a breakdown including metrics like Received by APNs, Delivered to Device, and Discarded - Token Unregistered. To track unregistered tokens on our end, we also monitor the 410 error responses from APNs, which typically indicate that a token is no longer valid. However, we’ve noticed a discrepancy: the number of 410 errors we receive is much lower than the Discarded - Token Unregistered count shown in the APNs console. Is this difference expected? Specifically, does APNs sometimes know that a token is unregistered but still return a success status to us when we attempt to send a push to that token? Thank you for any insights you can provide!