I created my app. One of its functionality is receive remote notification in the background (it receives it from Firebase Cloud Messaging via APNS) and replies with device location data. This is "boat tracking and alarm" type of app. It worked well both on my iPhone (where I use the same Apple ID as on developer's account) and on my son's iPad (different Apple ID). After the first review, when app was rejected with some remarks, background remote notifications completely stopped working on my iPhone. It looks like my iPhone put the app in permanent sleep. It never receives the background notifications. It receives them though in 2 case: when I open the app (it is no longer in background) when location is changed (it wakes app in the background). But the app should also respond when the device is stable at the position (I use both: precise and Significant Location Change. In the latter case changes are very rare). Btw, I scheduled a background task, not location, and it also never gets executed, so this workaround does not work. I describe it, so any Apple engineer does not get confused, verifying that these remote notifications reach the device. NO, they never get through when app is in the background (THIS IS THE PROBLEM), not that they are never delivered (the are, in the foreground). And the proof that it is not a problem with the app or remote notification construction is: they work on another drives (iPad) with no issues. Sometimes they are very delayed, sometimes almost instant. But usually they work. they worked the same way on my iPhone (with my developer's Apple ID) before the first rejection, and I haven't messed with messaging functionality since then. Now I am over with the last hope I had. I finally got my app release in App Store. I hoped official version would release some blockade my iOS put on my app. But unfortunately not. Official version works the same way as the test one. It works fine (receiving notifications in the background) on my son's iPad and it does not receive any background notification on my iPhone (100% block rate). Can anyone help me how can I reset my apps limits, the iOS created for my app? It seems that the rejection was a sparkle here - this is just a hint. I can provide any system logs for Apple engineers from both devices (iPhone and iPad) if you would like to check this case.

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.

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 am developing a VoIP service. Usually, when receiving a VoIP Push, Callkit is exposed immediately after receiving the message and the app is designed to be used. However, there is an extremely intermittent phenomenon (not well reproduced) where the app does not wake up even when receiving a VoIP Push. And after a long time, the app wakes up and Callkit is activated. (A long time after receiving the call…) Has anyone experienced the above phenomenon? I wonder if there are any reported parts depending on the OS version. (I have identified that it does not occur in the 17.x version, but it is difficult to guarantee because it occurs extremely intermittently) The app is not running in the background, but... Could this be happening if there are a lot of pending operations in the background? I need help urgently

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?

We have been getting several reports in the past 2 weeks of APNs notifications being either heavily delayed or not delivered at all. We have two apps, one of which has a Notification Service Extension and one of which does not. We have had users of both reporting sporadic notification problems. Looking at the sysdiagnose logs from one example, it looks like the notification was actually processed by our notification extension in a timely fashion, but was not displayed to the user. An example event we investigated it the following (now perhaps a little long in the tooth): 2025-10-31T14:32:54 apnsId=EE3E002D-26DE-B4F5-5E9B-5E0C1E1B6B3D We think we have correlated this with device logs: default 2025-10-31 10:32:54.472054 -0400 [EDE9521D-8A65-4588-8AE8-D3D78B9E5EA5] Received replacement content for notification request 859D-ABC7 [ hasContent: 1 attachments: 0 ] However there is no other reference until the app was launched about 1.5 minutes later: default 2025-10-31 10:34:26.875327 -0400 [..] Got 1 delivered notifications [ hasCompletionHandler: 1 ] When trying to reproduce, when I saw notifications bannered, the trace I saw was "Got 0 delivered notifications". What's the significance of "Got 1 delivered notifications" in this case? Historically, SpringBoard logs have shown detailed trace about the handling of notifications (which was very useful in narrowing down the slowness of notifications due to Apple Intelligence, reported on our side as FB16253547, which doesn't seem to have been triaged but it looks like was resolved around iOS 18.2.1 or iOS 18.3); however it seems that now sysdiagnoses are only containing <1 minute of trace from SpringBoard. Is there any way to extend the trace from SpringBoard that is included in sysdiagnoses? I see there was also https://developer.apple.com/forums/thread/806367 around the same time we started receiving reports. However I think my hypothesis is that this is a client-side issue, and notifications are being delivered to devices, just not presented correctly. Will try and collect a bit more data and file some Feedbacks and provide them here, but wanted to also flag here in case there are any others experiencing similar.

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.

My iPhone VoIP app, which I'm developing, uses Apple Push Notification service (APNs). I have a question regarding the following statement found in "[Overview of app transfer > Apps using push notifications]" Overview of app transfer You must manually reestablish push notification services if transferring an app that uses the Apple Push Notifications service (APNs). The recipient must create a new client SSL certificate using their developer account, as associated client SSL certificates, TLS certificates, and authentication tokens aren’t transferred. Question Let's say the recipient of the app transfer creates a "new SSL certificates, TLS certificates, and authentication tokens." Afterward, we need to verify that the Apple Push Notification service (APNs) works correctly when combining the transferred app with this "new SSL certificates, TLS certificates, and authentication tokens." However, until the recipient finishes verifying that it works correctly, the transferor want to keep the app available for download as before and be able to use the Apple Push Notification service. Is this possible? More specifically, can the recipient test the app to be transferred on TestFlight "before the transfer is completed"? I want to combine it with the "new SSL certificates, TLS certificates, and authentication tokens." and test it on TestFlight. Reading "[Initiate an app transfer]," it mentions the existence of a "Pending App Transfer" status. During this "Pending App Transfer" status, can the recipient test the app on TestFlight? Initiate an app transfer After you initiate the transfer, the app stays in its previous status, with the Pending App Transfer status added, until the recipient accepts it or the transfer expires after 60 days. Also, if there are any documents describing these procedures, I would appreciate it if you could share them. Thank you very much.

I am looking for advice for debugging a wallet pass not updating for some customers after successfully posting an APNS notification (pass identifier as topic, no expiration, priority 10). Is there an exhaustive list of reasons for a wallet pass not updating or a guide for making sure updates happen reliably? Are there are any guarantees made as to when the pass is updated? We noticed it is either never updating or the update happens much later for some customers. Usually toggling "Automatic Updates" in Pass Details updates the pass immediately for affected customers. Can it be caused by an error in the implementation of the Wallet Passes Web Service? We generate passes on the fly as a response to /v1/passes/{passTypeIdentifier}/{serialNumber}. I noticed that we also sometimes receive HEAD requests to this endpoint despite the documentation only mentioning the GET method. I was previously returning a HTTP status code 405 (Method Not Allowed). I have now updated it to also respond with headers (Content-Type, Content-Disposition and Last-Modified) for the pass for HEAD requests, but I don't know if it makes a difference. Here is a list of issues on the customer side I was thinking of: No connection to the internet Low power mode (does it prevent or throttle updates?) What happens if there is an error? Does it keep trying or does it just fail silently? In the latter case it might make sense to keep sending APNS notifications until the pass is requested successfully. I know that you can use the PassKit framework in iOS apps to update (replace) passes. Would this be more reliable than a stand-alone Wallet pass?

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://developer.apple.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://developer.apple.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://developer.apple.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://developer.apple.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!

I am developing a system to send VoIP notifications to terminals with APNs. I understand that the maximum JSON Payload for VoIP is 5kb. If I want to send VoIP notifications to 3000 terminals, I am considering sending 3000 requests in parallel from the system to the APNs, will the APNs guarantee that the notifications will be sent to each terminal without a significant time lag when receiving 3000 requests simultaneously?

ISSUE: CloudKit subscriptions are not triggering push notifications despite correct configuration. CloudKit logs show RecordSave events but NO NotificationSend events, indicating CloudKit is not attempting to send to APNS. CONTAINER: iCloud.Wunderkind.StrikeForceApp ENVIRONMENT: Tested in both Development and Production iOS 18.6.x Xcode 15.x (update with your version) Device: iPhone (not simulator) EVIDENCE: Subscriptions exist and are visible in CloudKit Dashboard Records are being created successfully (verified in logs) Device token is registered: 60eb962ff189dc5c2c0ef3e9d6643d72b4442a831bae224d2a553588b2e29139 Local notifications work correctly CloudKit logs show RecordSave but NO NotificationSend events STEPS TAKEN: Regenerated push certificates Disabled and re-enabled Push Notifications capability Deleted and recreated subscriptions Tested in both Development and Production environments Verified aps-environment entitlement matches environment Confirmed notification permissions granted SPECIFIC TEST: Creating a Challenge record with recipientRef matching my user triggers: ✅ RecordSave event in CloudKit logs ❌ No NotificationSend event ❌ No push notification received EXPECTED: CloudKit should send NotificationSend events and deliver push notifications when subscriptions match. ACTUAL: No NotificationSend events appear in CloudKit logs, no notifications delivered.

Could anyone play a sound from the Library/Sounds directory using alarmkit? Same file can play in app bundle, but not available in Library/Sounds directory. Is this by design?

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

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") }

Issue: Push notifications are not being received for some users. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving success responses from APNS. Users have confirmed that notifications are enabled on their devices, and they report no network issues.

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, I'm implementing the "Push to Start" feature for Live Activities, and I've run into an issue where the activity seems to be processed by the system but never appears on the Lock Screen or in the Dynamic Island. I suspect there's a silent crash happening in my widget extension immediately after launch, but I'm unable to capture any logs or crash reports in the Xcode debugger. Here is the flow and all the relevant data: 1. The Process My app successfully requests a pushToStartToken using Activity<EJourneyLiveActivityAttributes>.pushToStartTokenUpdates The token is sent to our server. The server uses this token to send a "start" event APNs push notification. The device console logs (from liveactivitiesd) show that the push is received and the system is "Publishing event". Expected Result: The Live Activity UI appears on the device. Actual Result: Nothing appears. The UI is completely absent. 2. Device Console Logs Here are the logs from the device console, which indicate a successful receipt of the push: pushServer default 12:08:22.716353+0200 liveactivitiesd Received push event for com.wavepointer.ejourney.staging::pushToStart pushServer default 12:08:22.716818+0200 liveactivitiesd Reduced budget for com.wavepointer.ejourney.staging::pushToStart to: 7 pushServer default 12:08:22.723458+0200 liveactivitiesd Publishing event: timestamp: 2025-07-24 08:57:19 +0000; activityIdentifier: 53C3EE9D-623C-4F38-93AE-8BB807429DAA; eventType: start(...) 3. APNs Payload This is the exact payload being sent from our server: { "aps": { "event": "start", "timestamp": 1753347375, "attributes-type": "EJourneyLiveActivityAttributes", "attributes": { "journeyId": "test123453" }, "content-state": { "distanceInMeters": 1000, "depTime": 1752745104, "arrTime": 1752748704, "depStop": "Arth, Am See", "arrStop": "Oberarth, Bifang", "depZone": "571", "arrZone": "566", "co2Save": 5.0, "co2SavePerc": 44, "companyName": "WP Innovation", "countryCode": "CH", "categoryId": 5, "subcategoryId": 3, "stationStartAssoc": "Assoc1", "stationEndAssoc": "Assoc2" } } } 4. ActivityAttributes Struct To prevent decoding errors, I have made all properties in my ContentState optional and added a custom decoder. @available(iOS 16.1, *) struct EJourneyLiveActivityAttributes: ActivityAttributes, Hashable { public struct ContentState: Codable, Hashable { var distanceInMeters: Int = 0 var depTime: Int = 1752843769 var arrTime: Int = 1752843769 var depStop: String = "" var arrStop: String = "" var depZone: String = "" var arrZone: String = "" var co2Save: Double? var co2SavePerc: Int = 0 var companyName: String = "Test" var countryCode: String = "CH" var categoryId: Int = 3 var subcategoryId: Int = 4 var stationStartAssoc: String? var stationEndAssoc: String? } var journeyId: String? } What I've Tried I have carefully checked that my Codable struct matches the JSON payload. I've made all properties optional to avoid crashes from missing keys. I have tried attaching the Xcode debugger to the widget extension process (Debug -> Attach to Process...) before sending the push, but no logs, errors, or crash reports appear in the Xcode console. The process seems to terminate before it can log anything. My question is: What could cause the widget extension to fail so early that it doesn't even produce a crash log in the attached debugger? Are there other methods to debug this kind of silent failure? Any help would be greatly appreciated. Thank you!

Apps distributed via TestFlight have a 90-day expiration period, and we have been sending push notifications to mobile devices daily. Will push notifications still be delivered to mobile devices after the app has expired?

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