In didFinishLaunchingWithOptions I have this setup for getting the token to send to my server for notifications. The issue is that the delegate callback didRegisterForRemoteNotificationsWithDeviceToken gets called twice when also initializing a CKSyncEngine object. This confuses me. Is this expected behavior? Why is the delegate callback only called twice when both are called, but not at all when only using CKSyncEngine. See code and comments below. /// Calling just this triggers `didRegisterForRemoteNotificationsWithDeviceToken` once. UIApplication.shared.registerForRemoteNotifications() /// When triggering the above function plus initializing a CKSyncEngine, `didRegisterForRemoteNotificationsWithDeviceToken` gets called twice. /// This somewhat make sense, because CloudKit likely also registers for remote notifications itself, but why is the delegate not triggered when *only* initializing CKSyncEngine and removing the `registerForRemoteNotifications` call above? let syncManager = SyncManager() /// Further more, if calling `registerForRemoteNotifications` with a delay instead of directly, the delegate is only called once, as expected. For some reason, the delegate is only triggered when two entities call `registerForRemoteNotifications` at the same time? DispatchQueue.main.asyncAfter(deadline: .now() + 4) { UIApplication.shared.registerForRemoteNotifications() } func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { print("didRegisterForRemoteNotificationsWithDeviceToken") }

We are developing an app that receives push notifications (via Firebase) from configured IoT devices. It is essential that when a specific type of notification is received, a sound is played continuously until the user interacts with the notification. This behavior is crucial for alerting users to certain critical states of the IoT device. We understand that Critical Alerts on iOS can bypass Do Not Disturb and silent mode. However, from our testing and available documentation, the sound from a Critical Alert seems to be limited to around 30 seconds. Our question: Is it possible on iOS to have a Critical Alert (or any other type of notification) continue playing sound until the user interacts with the notification or app? If so, could someone please point us to the appropriate documentation or APIs? Thanks in advance for any guidance.

Hello, I'm from Microsoft team maintaining push notification api behind Teams platform. We are experiencing strange and short error spikes towards APNS that seem to mostly correlate worldwide. We checked the networking and push request code but could not find what could be causing this. These error spikes are all timeouts or connection resets (by remote host, ie. APNS servers) and seem to come and go randomly: Would it be possible to check this for outages or some other metrics on your side or investigate why would it happen? Since it's worldwide it seems unlikely it's something broken on our side. We are using the standard APNS http2 endpoint with modern support for all RFC features (so everything should work normally). Mind you, our api might be in a unique position because of the volume of notifications (in the billions per day).

I'm encountering an issue with our legacy Objective-C codebase that uses UIApplicationDelegate. Here are the steps to reproduce the issue: Uninstall the application from the device. Install and launch the application. As part of the launch event, the client requests notification permission. The permission prompt is still displayed, even though the client receives a remote notification token (which appears to be a cached one). I followed the same steps with a sample app built with Swift (SwiftUI), and this issue did not occur. In the Swift app, I consistently received a delegate<didRegisterForRemoteNotificationsWithDeviceToken> call after the user allowed the notification permission. Could you please provide some insights into why this might be happening with only our client?

Hello, we have a problem with fake call on iPhone device for incoming calls. When I leave the iPhone in idle state for 30, 40 seconds and dialed voip app number the iPhone rings and there is no problem. When I leave it in idle for longer time one minute or two minutes I get "Call Failed to Connect" on iPhone's display and after this fake call I get second call with real calling number displays on iPhone. This first fake call is triggered by wake up push notification type 'voip'. If I switched off this wake up push notification type 'voip' and device's token has not expired yet I don't get fake call and iPhone's directly displays calling number. But in this situation we need to use wake up push notification type 'voip' on during a certain time to keep the device's token in our database and continuing to receive calling number without fake call. If we switched off the wake up push notification type 'voip' on certain time we need to activate again wake up push notification type 'voip' for incoming calls to wake up the iPhone. And in this way every time on every incoming call the iPhone's will display first fake call "Call Failed to connect" and after that the call with Calling number. How we can eliminate this fake call and use only one wake up push notification only for incoming calls not use second type wake up push on certain time? Thank you, I paste here our code for this: public ApnClient(IOptions settings) { var httpHandler = new HttpClientHandler() { ClientCertificates = { new X509Certificate2(certificate.Export(X509ContentType.Pfx)) }, }; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls13; this.httpClient = new HttpClient(httpHandler) { DefaultRequestVersion = HttpVersion.Version20, DefaultVersionPolicy = HttpVersionPolicy.RequestVersionOrHigher, BaseAddress = new Uri(settings.Value.ApnProdBaseUri), DefaultRequestHeaders = { { "apns-topic", ApnsTopic }, }, }; } public async Task<bool> WakeUpDevice(string deviceToken, string callId) { this.requestContent = new StringContent( $"{{\"aps\":{{\"content-available\":\"1\"}}}}", System.Text.Encoding.UTF8, "application/json"); var res = await this.httpClient.PostAsync($"/3/device/{deviceToken}", this.requestContent); return res.IsSuccessStatusCode; }

The following issue has occurred: Push notifications are not being received on certain devices. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving normal responses from APNs. Users have confirmed that notifications are enabled on their devices, and they report no network issues. This problem is occurring for multiple users.

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!!!

Hey Together, I have seen that critical notifications need to be confirmed by apple to be used. Sadly I couldn't figure out where to ask for that. Context: I have a sports tournament app for Beach Handball. There are a couple of Courts like up to 20-25. The main use for that in my app would be to notify first aiders/Medics. Right now they are called in via Speakers or by the referees just writing that into a WhatsApp chat. As this takes a long time and the speakers can be deactivated due to rain, power shortage or even the medics sometimes are not in range to exactly hear the speakers calling them. To Speed up this process I want them to download the App, Register via an E-Mail or a One Time Code. Now if a referee needs immediate Help from the Medics on their court they can send the Critical alert to the Medics without having to write a chat into a WhatsApp group, to get a call through the speakers 10 minutes later which the medics may not even hear. A couple of weeks ago we had a player falling on her back/neck/head and they couldn't figure out if she broke her neck or not. Luckily the medics were right next to the court and saw that. but what would happen if they were a couple hundred of meters away and did not notice that? I mean the PA system was off due to a power shortage. someone trying to move her? Risking her death? And while we are at it we could add those notifications if a team is missing to a court for a game that already should've started. Critical because it is urgent. Those notifications are handled with care.

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 According to documentation(https://aninterestingwebsite.com/documentation/usernotifications/handling-notification-responses-from-apns), APNs should return 410 status code with JSON body for invalid tokens Expected Behavior: APNs should return 410 status code when device token is no longer valid (app uninstalled) Thanks in advanced for support

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!

When User restarted iOS device, after powering on iOS App is not able to get VoIP push notification. If user opens App, immediate VoIP push receiving. In Normal (App Kill or Background state) everything works as expected. Issue is when device is powered on and immediately( In 1-2 mins) try to call on device. We are using delegate to show Call to User public func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void)

I am an iOS development engineer. Recently, I updated the Xcode version to 16.1 (16B40) and updated my debugging device (iPhone 15) to iOS 18.1.1. However, I found that I could not respond to the delegate method. I confirmed that my code, certificate, Xcode settings, and network environment had not changed. Simply executing application.registerForRemoteNotifications() in func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool did not receive a response(didRegisterForRemoteNotificationsWithDeviceToken or didFailToRegisterForRemoteNotificationsWithError ). In the same environment, when I switched to another device for debugging (iOS 17.0.3), the delegate method would respond. I really don't know what to do, I hope someone can help me, I would be very grateful. Please note: Everything is normal when using devices before iOS 18.1.1 version

Hello everyone, Our team is currently developing a PTT (Push-to-Talk) application using the officially recommended PushToTalk framework. During development, we've encountered a point of confusion regarding the application's behavior after being force-quit by the user. Based on our understanding of the PushToTalk framework documentation (https://aninterestingwebsite.com/documentation/pushtotalk/creating-a-push-to-talk-app/) and the PTChannelManager session restoration mechanism, when a user manually kills the app from the background (App Switcher), the current PTT session (the system session managed by PTChannelManager) should terminate. Subsequent pushtotalk type pushes sent via APNS, without an active session, appear to be silently discarded by the system and cannot wake the app for processing (similar to what Kevin Elliott DTS mentioned in https://aninterestingwebsite.com/forums/thread/760506 Point D). This seems to prevent reliable PTT message reception in our app after a user force quits. However, we've observed that some popular PTT applications on the market (e.g., TenTen) appear to successfully receive and play PTT voice messages from friends even after the user has performed a force-quit action. This behavior seems inconsistent with our test results and understanding based on the standard framework, posing a challenge for us in providing similar reliability using standard methods. This naturally leads us to wonder how this capability is achieved. We've reviewed developer forums and are aware of the historical existence of a PTT-specific com.apple.developer.pushkit.unrestricted-voip entitlement, which allowed PushKit usage for PTT without CallKit binding. While Apple DTS engineers have repeatedly stated this entitlement is being deprecated and urged migration to the PushToTalk framework (e.g., https://aninterestingwebsite.com/forums/thread/763289), we are curious if the observed "wake-after-force-quit" capability might be related to some apps potentially still utilizing this outgoing special entitlement. Alternatively, is there perhaps a mechanism within the standard PushToTalk framework that allows wake-up after force quit that we haven't fully grasped? Therefore, we'd like to ask fellow developers for clarification and discussion: When using the standard PushToTalk framework, have others confirmed that the app indeed cannot be woken up by pushtotalk pushes after being force-quit by the user? Is this the expected behavior? Has anyone successfully achieved a TenTen-like experience (reliable PTT reception after force quit) using only the standard PushToTalk framework? If so, could you share key implementation insights or areas to focus on? (e.g., Is it related to specific usage patterns of the restorationDelegate?) How do you view this potential discrepancy between standard framework capabilities and the behavior exhibited by some apps? What considerations does this bring to development planning and user experience design (especially when users might have expectations set by the "always-on" behavior of other apps)? Are there any best practices or specific techniques when using PTChannelManager session management and restoration that maximize PTT message reliability (especially after the app is terminated by the system in the background), while still adhering to the framework's design principles (like user awareness of the session via UI)? [For instance, another developer raised challenges related to PTT framework restrictions here: https://aninterestingwebsite.com/forums/thread/773981] We hope this discussion can help clarify our understanding of the framework and gather community best practices for building reliable PTT functionality while adhering to Apple's guidelines. Thanks for any insights or shared experiences!

We are in the process of transferring our app to a new Apple Developer Organization account. Our app uses the Apple Push Notification service (APNs) with a .p8 authentication key configured on our server to send push notifications. We would like to confirm: Once the app transfer is completed, will push notifications continue to work temporarily using the existing .p8 key on our server, until we generate and configure a new .p8 key under the new organization's account? Understanding this behavior is critical for us to ensure a smooth transition and avoid any disruption in push notification delivery for our users. Thank you for your guidance and support.

Provisioning profiles created for my App ID are not including the Push Notifications capability, even though Push Notifications is enabled in the App ID configuration in Apple Developer Portal. I have enabled Push Notifications for my App ID (com.abc.app) in the Apple Developer Portal. The capability shows as enabled and saved. However, when provisioning profiles are generated (either manually or through third-party tools like Expo Application Services), they do not include: The Push Notifications capability The aps-environment entitlement This results in build failures with the following errors: Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't support the Push Notifications capability. Provisioning profile "*[expo] com.abc.app AppStore [timestamp]" doesn't include the aps-environment entitlement. Steps Taken ✅ Enabled Push Notifications in App ID configuration (com.mirova.app) ✅ Saved the App ID configuration multiple times ✅ Waited for Apple's systems to sync (waited 5-10 minutes) ✅ Removed and re-added Push Notifications capability (unchecked, saved, re-checked, saved) ✅ Created Push Notification key in Apple Developer Portal ✅ Verified Push Notifications is checked and saved in App ID ❌ Provisioning profiles still created without Push Notifications capability Expected Behavior When Push Notifications is enabled for an App ID, any provisioning profiles created for that App ID should automatically include: Push Notifications capability aps-environment entitlement (set to production or development) Actual Behavior Provisioning profiles are created without Push Notifications capability, even though: Push Notifications is enabled in App ID App ID configuration is saved Sufficient time has passed for sync Additional Information Push Notification Key: Created and valid (Key ID: 3YKQ7XLG9L and 747G8W2J68) Distribution Certificate: Valid and active Provisioning Profile Type: App Store distribution Third-party Tool: Using Expo Application Services (EAS) for builds, but issue persists with manually created profiles as well Questions Is there a delay or sync issue between enabling Push Notifications in App ID and it being available for provisioning profiles? Are there any additional steps required to ensure Push Notifications is included in provisioning profiles? Is there a known issue with Push Notifications capability not being included in provisioning profiles? Should I create the provisioning profile in a specific way to ensure Push Notifications is included? Environment Platform: iOS Build Type: App Store distribution Xcode Version: (via EAS cloud build) Thank you for your assistance. I've been unable to resolve this issue and would appreciate any guidance. iOS Deployment Target: Latest

we already got access to com.apple.developer.usernotifications.filtering , we have set up this special permission in our app extension entitlement and provision profile. but we are still unable to filter notification by providing empty UNNotificationContent

Hi, We have a simple calendar reminder app that uses UNNotificationRequest to schedule local notifications for user events. I’m wondering whether UNNotificationRequest has a system-imposed limit of 64 upcoming scheduled notifications, similar to the deprecated UILocalNotification. We’re asking because one of our users is not receiving recently scheduled reminders. Our current workflow is: We schedule notifications on app launch and when the app is about to quit. Before scheduling, we call removeAllPendingNotificationRequests(). We then fetch the 64 nearest upcoming events and schedule them using UNUserNotificationCenter.current().add(...). This approach works fine during our testing, but we’re unsure what might be causing the issue for some users. Any insights would be appreciated. Thanks!

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.

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.

iOS push notification is not working for in App since 03-Apr-2025. We are pushing the message to APNS from our application, but message is not delivered to iOS device. We have performed tests on both PROD and QA environment and following are the observations: PROD successfully pushing the notification to APNS but not receiving the notification on iOS device (100% failure). QA received notification on iOS device always (100% success). Analyzed PROD notification server log at our end and we do not observe any error and it is showing successful also when message is pushed to APNS all the time. Need to check from APNS why push messages are not delivered to iOS devices. Validated the PROD APNS certificate at our end which we are using during call to APNS - it is valid till Oct 2025. Please suggest me any possible solution because I don't have any clue where it is failing and what to do