We've had reports that since upgrading to iOS 18.1.1, wallet pass notifications (on the lock screen) now display "Nearby" instead of the Departure time,. Has anyone else experienced this issue? There doesn't seem to be any documentation around it. Thanks

self.pushRegistry = [[PKPushRegistry alloc] initWithQueue:dispatch_get_main_queue()]; self.pushRegistry.delegate = self; self.pushRegistry.desiredPushTypes = [NSSet setWithObject:PKPushTypeVoIP]; //处理接收到的VoIP推送 (void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void(^)(void))completion then we send message from our server or from apple's cloud service: https://icloud.developer.apple.com/dashboard/notifications website services: when app is in foreground,withCompletionHandler wil be called correctly,but when app is in background or has killed ,withCompletionHandler not be called!!! the background fetch、voice over ip is checked in signing & capabilities tabs why?why?why?why?why?why?why?why?why?

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

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?

I'm attempting to leverage notifications in an app that is in Swift 6 language mode. I have the following code: func startLocationUpdates() { //if self.manager.authorizationStatus == .notDetermined { // self.manager.requestWhenInUseAuthorization() //} self.logger.info("Starting location updates") Task { do { let updates = CLLocationUpdate.liveUpdates() for try await update in updates { if !self.updatesStarted { break } // End location updates by breaking out of the loop. self.lastUpdate = update if let loc = update.location { self.lastLocation = loc self.isStationary = update.stationary self.count += 1 self.logger.info("Location \(self.count): \(self.lastLocation)") } if lastUpdate!.insufficientlyInUse { let notification = UNNotificationRequest(identifier: "com.example.mynotification", content: notificationContent, trigger: nil) try await UNUserNotificationCenter.current().add(notification) } } } catch { self.logger.error("Could not start location updates") } return } } As an aside, the above is directly taken from the following sample: https://developer.apple.com/documentation/CoreLocation/adopting-live-updates-in-core-location. With Swift 6 language mode enable, this generates a compiler error for the statement: try await UNUserNotificationCenter.current().add(notification) Sending main actor-isolated 'notification' to nonisolated instance method 'add' risks causing data races between nonisolated and main actor-isolated uses How can I fix this?

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 got some problem for the LiveAcitvity when i start it with notification. The LiveActivity can not show,but it can work when i update or end a LiveActitvity; And so,i think my configeration is right like the code; thanks in advance

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

Hey there, i implemented live activity in my app and iam trying to start the live activity from push notification, updates works fine even when the app is in background but starting the activity creating issue mostly on background and kill mode when i check the delivery of live activity on cloudkit console it says stored for device power considerations. anyone having the same issue ?

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?

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

Having some discussion about when we should clear out a token from our servers. Docs say: Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. You can retry with a delay, if you get the error code TooManyRequests. The way I see it is that with the exception of PayloadTooLarge, all other errors means you should remove the token from your server. Either because: The token is no longer good The token is good, but this is just not the right: environment (sandbox vs production) topic (the token is from a different bundle id or developer team) target (app vs live activity appex) Do I have it right? Extra context: when using the "JSON Web Token Validator" tool, a colleague reported that a 410 -Expired token (from couple days back) was still valid today. This raises questions about when tokens should actually be deleted and how these error codes should be interpreted. Also is it possible for the docs to get updated for us to explicitly know if a token should get removed and not leave it for interpretation?

Hi team, I am developing VOIP feature using PushKit and CallKit but CallKit is not show when app in background or terminate state, now in foreground state I can call reportNewIncomingCall from pushRegistry-didReceiveIncomingPushWith and it's work as expected but the problem is in background or terminate state it's not my setup: PushKit is configured In Signing & Capabilities I add background modes (Remote notifications and Voice over IP) In info.plist I add <key>UIBackgroundModes</key> <array> <string>voip</string> I'm not sure should I create new VOIP Certificate but now I can receive message notification normally. Any help or suggestions would be greatly appreciated Thank you

Hi all, I’m running into an issue with provisioning profiles not including the com.apple.developer.push-notifications entitlement — even though everything seems to be configured correctly. Here's what I’ve done: Checked the App ID has Push Notifications enabled. I’ve clicked “Configure” and created a Production APNs certificate under the App ID. I’ve regenerated the provisioning profiles (Ad Hoc and App Store). I can see within the profiles within App Store Connect that the push notifications capability is listed I’ve downloaded and decoded the profiles using: security cms -D -i profile.mobileprovision &gt; decoded.plist But com.apple.developer.push-notifications is still missing under the &lt;key&gt;Entitlements&lt;/key&gt; block. This is causing issues because: When I submit the build to eas I receive this error from XCode: - Provisioning profile "*** Adhoc" 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. (in target '***' from project '***') Refer to "Xcode Logs" below for additional, more detailed logs. To isolate the issue further I: Created a completely new App ID, enabling Push Notifications from the start. Created new APNs certificate. Generated new provisioning profiles with a valid distribution certificate. Still no push entitlement embedded in the profile. Question: Has anyone else encountered this issue where Push Notifications are enabled and configured, but the entitlement still fails to embed in the profile? Thanks in advance.

Do we need this new certificate "SHA-2 Root : USERTrust RSA Certification Authority certificate" if we are using token based authentication with APNs? We are signing the JWT with the private Auth key? Or is the new certificate needed on top of this? We are doing something like this: Dictionary<string, object> payload = new Dictionary<string, object>() { { "iss", teamId }, // Apple Developer Team ID { "iat", unixTimestamp } // Issued-at time }; Dictionary<string, object> header = new Dictionary<string, object>() { { "alg", "ES256" }, { "kid", keyId } // Key ID from Apple Developer portal }; string token = JWT.Encode(payload, privateKey, JwsAlgorithm.ES256, header);

After updating to iOS 26 beta 1, I can't receive any push notifications from most applications. I can receive notifications from like Calendar, which uses local & reserved notifications, but I can't receive any remote-based notifications.

Our mobile app uses a specific platform for subscription management. At this time,, it's integration with Apple notifications is built around the Server-to-Server Notifications v1 and the traditional verifyReceipt endpoint. At this time, it does not support Server-to-Server Notifications v2, nor has any published documentation or resources on a custom integration path using v2. Our app is built using Flutter and we handle purchases with the in_app_purchase plugin. However, due to the limitation on the system for subscription side, we need to connect to Apple’s legacy server-to-server subscription endpoints (StoreKit v1) to receive real-time notifications and validate receipts. Could you please provide information how to do it?

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?