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

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?

In the new AlarmKit API, how do you localize NSAlarmKitUsageDescription? In the case of other usage descriptions, such as NSLocationWhenInUseUsageDescription, you can use an InfoPlist.xcstrings file, but this does not appear to work for NSAlarmKitUsageDescription.

iOS app crashes on launch after updating and adding push notifications, but no crash logs are received; however, it works fine after restart. What could be the reason? launch failed, RBSProcessExitContext voluntary

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.

I'm trying to rewrite a Swift code to Swift 6 language mode and am stuck with this problem. How do I safely pass the bestAttemptContent and contentHandler to the Task? This is from the UNNotificationServiceExtension subclass. final class NotificationService: UNNotificationServiceExtension { var contentHandler: ((UNNotificationContent) -> Void)? var bestAttemptContent: UNMutableNotificationContent? var customNotificationTask: Task<Void, Error>? override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { self.contentHandler = contentHandler bestAttemptContent = (request.content.mutableCopy() as? UNMutableNotificationContent) guard let bestAttemptContent = bestAttemptContent else { invokeContentHandler(with: request.content) return } do { let notificationModel = try PushNotificationUserInfo(data: request.content.userInfo) guard let templatedImageUrl = notificationModel.templatedImageUrlString, let imageUrl = imageUrl(from: templatedImageUrl) else { invokeContentHandler(with: bestAttemptContent) return } setupCustomNotificationTask( imageUrl: imageUrl, bestAttemptContent: bestAttemptContent, contentHandler: contentHandler ) } catch { invokeContentHandler(with: bestAttemptContent) } } // More code private func downloadImageTask( imageUrl: URL, bestAttemptContent: UNMutableNotificationContent, contentHandler: @escaping (UNNotificationContent) -> Void ) { self.customNotificationTask = Task { let (location, _) = try await URLSession.shared.download(from: imageUrl) let desiredLocation = URL(fileURLWithPath: "\(location.path)\(imageUrl.lastPathComponent)") try FileManager.default.moveItem(at: location, to: desiredLocation) let attachment = try UNNotificationAttachment(identifier: imageUrl.absoluteString, url: desiredLocation, options: nil) bestAttemptContent.attachments = [attachment] contentHandler(bestAttemptContent) } } } I tried using the MainActor.run {}, but it just moved the error to that run function. The UNNotificationRequest is not sendable, and I don't think I can make it so. Wrap the setupCustomNotification in a Task will move the errors to the didReceive method. It seems like the consuming keyword will help here, but it leads to a compilation error, even with the latest Xcode (16.2). Any pointers?

Hi Apple Dev Team, We have a React Native application that includes call functionality using PushKit and VoIP notifications. We are using APNS to send the VoIP notifications, and everything has been working smoothly on iOS versions up to 18.3.1. However, after updating to iOS 18.4, we are no longer receiving incoming VoIP push notifications on the device. There have been no code changes related to our PushKit or notification logic — the exact same build continues to work correctly on devices running iOS 18.3.1 and earlier. We're trying to understand if anything has changed in iOS 18.4 that affects VoIP push delivery or registration behavior. Would appreciate any guidance, and happy to share code snippets or configuration if needed. Thanks in advance!

I have been watching the following moment from wwdc (Design dynamic Live Activities): https://developer.apple.com/videos/play/wwdc2023/10194/?time=728 It suggest that you should 'tick' between multiple live activities of your app: When you want to show multiple sessions for your app going on at once, consider ticking between the display of them to continue to give users an eye on everything that’s going on. How can I tick between them? More specifically how can I do that when my app is in the background?

Dear Apple Engineer Recently we found that our push delivery rate has decreased. On the website "https://icloud.developer.apple.com/dashboard/notifications/teams/43Y657P48S/app/com.taobao.fleamarket", we found that starting from January 8, 2025, "Discarded - Token Unregistered" showed an upward trend, from millions to tens of millions. We have not found the reason, and hope you can help us. Team ID: 43Y657P48S Bundle ID: com.taobao.fleamarket Here are some failed tokens, in "Device Token Validator" The query is valid, but the user cannot receive the message: 56025f656cc3aa701898037f59e8d0cb937263ff5585cd1cec9ae661dcc15b19 5fbbd1e604d3662d7583e9377676f8fa276005145278d6dea04b4fc85a7b070e f0970602551f8d249d8f97960a74006ad78688b52fec6b0d19a585 207caff62e 9388fb40209c100afc2db728342f6fe86c7e34787a8fe4a92b73d2503c5286e0 a2819a4708462588b07452ed827d9afb03c343b586e70dcb67a9981f76295704 8949373cd43783fa3e23d38d55ee1fd72475b39f9c2d2fedca3ecb925b094240 Best Regards!

Observations​​: When our app calls the APNs API for push notifications, we observed significant fluctuations: July 15-25​​: The success response volume ​​increased by 20%​​ compared to the baseline before July 15. ​​After July 25​​: Success rates returned to baseline levels. July 30​​: Success response volume ​​decreased by 10%​​ compared to the pre-July 15 baseline. ​​ Excluded Factors​​: No changes in target audience size or characteristics (business factors ruled out). Server logs confirm consistent API request parameters and frequency. ​​Key Questions​​: Were there any ​​adjustments to response metrics​​ (e.g., success status code definitions) during this period? Have other developers reported similar issues? Were there server-side configuration updates or known incidents on Apple’s end?

We are observing unexpected behavior in Apple Push Notification Service (APNS) delivery and would appreciate clarification and guidance. Below is a detailed breakdown of the scenario and related questions. Abbreviations: APNP – Apple Push Notification Provider APNS – Apple Push Notification Service Scenario: User1 is registered on iOS device1. Flight Mode is enabled on iOS device1. User2 initiates a call to User1 (Time t = 0 sec). User2 cancels the outgoing call after 5 seconds (Time t = 5 sec). Flight Mode is disabled on iOS device1 after 20 seconds (Time t = 25 sec). Observation: iOS device1 displays an incoming call notification (CallKit UI) after flight mode is turned off, despite the call being cancelled by User2. This notification disappears automatically after approximately 8–10 seconds. Logic Flow: At time t = 0, our APNP sends a VoIP push (priority) to APNS for the incoming call. Since device1 is in flight mode, APNS cannot deliver the push. At t = 25 sec, after flight mode is turned off, APNS delivers the cached VoIP push to device1. The app takes ~5 seconds to initialize (CSDK setup, SIP registration, etc.). It eventually receives a SIP NOTIFY with state="full" and empty dialog info (indicating no active call). Consequently, the CallKit incoming call is removed after ~8 seconds. Questions: → We set the apns-expiration header to 0, expecting that the VoIP push would not be delivered if the device was unreachable when the push was sent. However, APNS still delivers the push 20–30 seconds later, once the device is back online. Q. Why is the apns-expiration header not respected in this case? → Upon receiving the VoIP push, we require ~10–12 seconds to determine if a visible CallKit notification is still relevant (e.g., by completing SIP registration and checking for active dialogs). Q. Is it acceptable, per Apple guidelines, to intentionally delay showing the CallKit UI (incoming call) for 10–15 seconds after receiving the VoIP push? → Apple documentation states that the priority VoIP push channel should be used only for notifying incoming calls, while regular (non-VoIP) pushes should be used for other updates, including call cancellations. Q. What is the rationale behind discouraging the use of the priority VoIP push channel for call cancellation events? In some cases, immediate cancellation notification is as critical as the initial incoming call. Would Apple consider it acceptable to occasionally use the priority VoIP channel for rare call-cancellation scenarios without risking throttling or suspension? → In our implementation, we send an incoming call notification via the priority VoIP channel. Shortly after, we send a call cancellation notification on the regular push channel, marked with "content-available": 1. We expect this regular push to wake the app (triggering application:didReceiveRemoteNotification:fetchCompletionHandler:), but in practice the app never wakes, and our debug logs inside that delegate method never appear. Q. Under what exact conditions does a "content-available": 1 regular push fail to wake the app when it follows a VoIP push? Are there additional requirements (e.g., background modes, rate limits, power optimizations) that could prevent the delegate from being called? → According to Apple documentation: “APNs stores only one notification per bundle ID. When multiple notifications are sent to the same device for the same bundle ID, APNs keeps only the latest one.” However, in our tests: If a device is offline when APNs receives both: (a) a priority VoIP push for an incoming call, (b) a regular push for call cancellation (same bundle ID), Upon the device reconnecting, APNs still delivers the earlier VoIP push, instead of discarding it and delivering only the most recent (cancellation) notification. Q. Why doesn’t APNs replace the queued VoIP push with the newer regular push when both share the same bundle ID? Is this expected behavior due to channel type differences (VoIP vs. regular), or is there a way to ensure that the latest notification (even if regular) supersedes the earlier VoIP push? We’d appreciate your input or recommendations on handling such delayed pushes and any best practices for VoIP push expiration handling and call UI timing.

I am sending push notification using HTTP/2 to https://api.push.apple.com:443 api but I am getting Operation TimeOut error in response . Can someone help

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 Thanks in advanced for support

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!

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?

Facing issue while sending push notification through the application. The APNs certificate is valid. Below is the error log. System.AggregateException: One or more errors occurred. ---> PushSharp.Apple.ApnsNotificationException: Apns notification error: 'ConnectionError' ---> System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndSend(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndWrite(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.Security._SslStream.EndWrite(IAsyncResult asyncResult) at System.Net.Security.SslStream.EndWrite(IAsyncResult asyncResult) at System.IO.Stream.<>c.b__53_1(Stream stream, IAsyncResult asyncResult) at System.Threading.Tasks.TaskFactory1.FromAsyncTrimPromise1.Complete(TInstance thisRef, Func3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at PushSharp.Apple.ApnsConnection.<SendBatch>d__21.MoveNext() --- End of inner exception stack trace --- at PushSharp.Apple.ApnsServiceConnection.<Send>d__2.MoveNext() --- End of inner exception stack trace --- ---> (Inner Exception #0) PushSharp.Apple.ApnsNotificationException: Apns notification error: 'ConnectionError' ---> System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndSend(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndWrite(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.Security._SslStream.EndWrite(IAsyncResult asyncResult) at System.Net.Security.SslStream.EndWrite(IAsyncResult asyncResult) at System.IO.Stream.<>c.<BeginEndWriteAsync>b__53_1(Stream stream, IAsyncResult asyncResult) at System.Threading.Tasks.TaskFactory1.FromAsyncTrimPromise1.Complete(TInstance thisRef, Func3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at PushSharp.Apple.ApnsConnection.d__21.MoveNext() --- End of inner exception stack trace --- at PushSharp.Apple.ApnsServiceConnection.d__2.MoveNext()<---

Hello, I recently had an unusual experience, and I’m wondering if this is related to Apple’s policies, so I wanted to ask. While a call is in Picture-in-Picture (PIP) mode, notification pushes from the same app do not appear. The API is being triggered, but the notification banner does not show on the device. Once PIP is closed, the notifications start appearing normally again. Is this behavior enforced by Apple’s policies? What’s interesting is that banners from other apps do appear — only the banners from the app currently in PIP are not shown.

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'm running into an issue during the iOS build process for my app, and I'm hoping someone can point me in the right direction. ❗ The Problem When attempting to archive the app via EAS Build (Expo), the build fails with the following error: `Provisioning profile "HCF_AppStore_ProvisioningProfile" doesn't include the com.apple.developer.push-notifications entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update.` What I’ve Already Done: Enabled Push Notifications capability for the App ID (com.rsmco.helpcreatefamilies) in the Apple Developer portal. Deleted and regenerated the App Store Provisioning Profile after enabling the capability. Confirmed the new profile is associated with the correct App ID and Distribution Certificate. Uploaded the new profile to EAS (Expo) and rebuilt the app. Yet the error persists during the Xcode archive step with Exit code 65. Additional Info: Provisioning Profile Name: HCF_AppStore_ProvisioningProfile App ID: com.rsmco.helpcreatefamilies Team: Reproductive Sciences Management Company, LLC Workflow: Expo EAS Build Capability causing issue: com.apple.developer.push-notifications

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?