Hi, We operate several iOS apps that use APNs through the HTTP/2 provider API. Since around May 12, we have observed a significant drop in APNs HTTP/410 “Unregistered” responses across multiple apps / bundle IDs. There have been no relevant changes on our side around that time. Our APNs integration, request flow, credentials, and push token handling have remained unchanged. What makes this more confusing is that App Store Connect does not show a corresponding drop in app deletion events for the same apps and time period. In other words, the app deletion trend appears stable in App Store Connect, but APNs 410 “Unregistered” responses dropped sharply. We understand that APNs does not guarantee an immediate 410 response after an app uninstall, and that the exact token invalidation timing is not documented. However, the aggregate change in 410 response volume is large enough that it looks like a behavior change. Questions: Has there been any recent APNs behavior change around when device tokens are marked inactive after an app is uninstalled? Were there any APNs-side changes around May 12 that could affect the rate of HTTP/410 “Unregistered” responses? Why might App Store Connect app deletion events remain stable while APNs 410 “Unregistered” responses drop significantly? Is APNs expected to return HTTP/200 for an extended period for tokens that may no longer be active for the topic? Thanks.

We have an app that uses PushKit and CallKit for video calling. These are often emergency calls, so very latency-sensitive. We keep track of when we sent out the APNs request and when the phone started ringing. The p95 latency is about 2 seconds (mean is ~800ms), which feels quite long.. Is this normal? I'd expect <500ms most of the time given that the devices and servers are all within the US. The users typically have a stable internet connection. Our requests look like this: POST https://api.push.apple.com/3/device/<DEVICE_TOKEN> apns-topic: com.vpt.physician.voip apns-push-type: voip apns-priority: 10 apns-expiration: 0 authorization: bearer <APNS_PROVIDER_TOKEN> content-type: application/json {  "aps": {    "content-available": 1  },  "title": "Example Text",  "type": "CallFromTablet",  "timeout_ms": 30000 } If there's any more info I can provide to help troubleshoot this, let me know. Thanks in advance.

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

Hello, We are planning to transfer an app to a different Apple Developer account and had several questions regarding APNs continuity and behavior after the transfer. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. I’ve done some due diligence on this topic within the forums and found related guidance here: https://developer.apple.com/forums/thread/744468?answerId=776692022#776692022 My understanding from that thread is that the existing push notification credentials will become invalid after a short delay following the transfer, and that we would need to update our backend to use newly generated credentials from the recipient account. However, since things can evolve over time, I wanted to confirm whether that guidance is still accurate for the following scenarios. For users who already have the app installed and previously opted into push notifications before the transfer: Will existing APNs device tokens remain valid after the app transfer? Will these users continue receiving push notifications without interruption, assuming our provider infrastructure remains unchanged? For users who newly install the app after the transfer: Will we need to migrate to a new APNs authentication key or certificate associated with the recipient Apple Developer account in order to successfully register for and send push notifications to those users? For users who restore or migrate the app to a new device (for example, via iCloud Backup restore or device-to-device transfer): Will push notification registration continue to function normally after the app transfer? Will those app instances need to re-register and obtain new APNs device tokens associated with the recipient account? To support this scenario, would our provider infrastructure need to migrate to and use a new APNs authentication key associated with the recipient account? Any clarification on the expected APNs transition behavior during and after an app transfer would be greatly appreciated. Thank you.

Hello, We are going to transfer our App to another company’s Apple Developer account. We have been using P12 certificates and P8 keys for APNs push service, and we have several inquiries: Will the current P12 push certificates expire instantly after successful App transfer? Is it mandatory to recreate P12 certificates under the new account? Will existing P8 keys be disabled immediately after the ownership transfer? Do we need to generate new P8 keys under the new account? Without releasing new App builds and updating push credentials after the transfer, can existing end users still receive normal push notifications? Thanks a lot for your assistance, waiting for your reply.

Hello, I have a question regarding push services after app transfer completion and hope you can clarify it for me: If the original team does not actively disable existing APNs and JWT connections as well as push services, will the old P12 certificates and P8 keys remain valid for a short while so users can still receive push notifications? If yes, the new company only needs to finish certificate updates shortly after receiving the transfer success notice. How many hours is this grace period normally? Whether the original team shuts down APNs and JWT services or not, will the old P12 certificates and P8 keys become invalid right away, leaving users unable to receive pushes until the new company updates the relevant credentials? Thanks for your support and looking forward to your reply.

We are working on a feature that uses geo-based local notifications to target users when they arrive at an airport. Our implementation uses UNLocationNotificationTrigger with CLCircularRegion. The local notification is scheduled after the user has granted notification permission and location permission. We are currently using “While Using the App” location permission and with enabled location updates in capabilities We have used CLMonitor as well for the same. However, we are seeing inconsistent accuracy and missed triggers, even after testing with users who have granted the required permissions. we did use CLMonitor as well but we are getting the trigger on the entry of specified region. Could you please help us understand the constraints and expected behavior for location-based notification triggers on iOS? Specifically, we would like guidance on the following: What parameters influence UNLocationNotificationTrigger accuracy and reliability? What is the recommended minimum radius for geofencing around large areas such as airports? Does “While Using the App” permission have any practical limitations for location-based local notification delivery? Are there system-level conditions that may prevent or delay the trigger, such as Precise Location being off, Low Power Mode, Focus mode, Background App Refresh, airplane mode, or poor GPS/network availability or any others? Are there recommended best practices for improving reliability for an airport-arrival use case?

I'm seeing a timestamp display issue on Apple Watch Notification Center, and I'd like to confirm whether this is a known watchOS behavior or whether there's a setup mistake on our side. Symptom The same APNs notification displays the correct time on iPhone Notification Center and on the initial Apple Watch banner. After the Watch screen turns off and the user later opens Notification Center on Apple Watch, the same notification may show an incorrect relative timestamp such as "3 hours ago" or even "yesterday". The drift is per-notification and persists for that notification until it's dismissed. iPhone NC always shows the correct time. WhatsApp tested side-by-side on the same iPhone/Watch pair does not show this drift. Setup iOS 26.4.2 on iPhone 16 Pro watchOS 26.4 on Apple Watch Series 10 App with paired Apple Watch A UNNotificationServiceExtension that decrypts E2EE message previews and applies Communication Notification enrichment via INSendMessageIntent and content.updating(from:) Production APNs environment, TestFlight builds No beta software Isolation tests already performed Test mutable-content NSE invoked Drift on Watch NC Minimal APNs (alert + sound only) no no no drift NSE skips content.updating(from:), INInteraction.donate/delete (still calls them as no-op via diagnostic build) yes yes — modifies content drift NSE bypasses ALL Intents/Communication Notification APIs (no INPerson, no INSendMessageIntent, no avatar, no updating(from:)); just modifies title/body/sound/category and returns the mutable copy yes yes — modifies content drift Production-like APNs payload (thread-id, target-content-id, category, sound, badge, custom userInfo) but WITHOUT mutable-content no no no drift Eliminated as causes: content.updating(from:), INSendMessageIntent, INInteraction.donate, INInteraction.delete(with:), INPerson/INPersonHandle (not even constructed in test 3), avatar fetching, thread-id, target-content-id, category, sound, badge, custom userInfo, custom createdAt timestamp, stale Siri/Apple Intelligence history (cleared manually on iPhone and Watch). The pattern The only consistent variable distinguishing the no-drift cases from the drift cases is whether mutable-content: 1 is set on the APNs payload (i.e. whether the UNNotificationServiceExtension is invoked). Once invoked, the extension's behavior with respect to Communication Notifications does not seem to affect the outcome — the drift reproduces even when the NSE only modifies title/body/sound and returns. Questions Is there a known watchOS behavior where notifications processed by a UNNotificationServiceExtension use a different timestamp source on Apple Watch Notification Center after the Watch screen has been turned off and reopened, while the initial Watch banner and iPhone Notification Center show the correct delivery time? Are there specific UNMutableNotificationContent properties or APNs payload flags that should be preserved (or avoided) when returning content from an NSE to keep the Watch NC timestamp consistent with the delivery time? For E2EE messaging apps, is there a recommended pattern to decrypt and return content from an NSE that avoids this drift on watchOS? Happy to provide an anonymized snippet of NotificationService.swift and the APNs payload format if useful. Thanks.

I am running into an issue where if a user has denied normal notifications but allowed Critical Alerts, they do not receive the Critical Alert. Apple documentation specifies that Critical Alerts will override device Silent and Do Not Disturb settings, but it does not clearly state if it does or does not override the Allow Notifications setting for that particular app. Is this intended behavior? Seems like a bug, as a user could definitely want to filter out notifications that are not critical.

Hi, I have a question regarding the relationship between the Apple Developer Enterprise Program membership and an existing APNs certificate used for MDM. Current Situation We are operating an MDM server. We have already obtained a valid APNs certificate via the Apple Push Certificates Portal. Our Apple Developer Enterprise Program membership is about to expire. The only asset we have in the Enterprise account is the MDM CSR used during the APNs certificate issuance process. Question If the Apple Developer Enterprise Program Membership expires: Will the existing APNs certificate remain valid until its expiration date? Or will it become invalid immediately due to the account expiration? Thank you.

For many months now we've been building a watchOS app with push support. On device, these usually work fine, but in the sim, only loud pushes are ever received (don't contain content-available). This includes pushes triggered from our backend, whether directly or through Firebase Cloud Messaging, from Apple push web interface, from apns files dropped onto the sim, or from files sent using simctl push. All say they were sent successfully, none trigger any of the push related WKApplicationDelegate methods. As I understand it, only didReceiveRemoteNotification should be triggered for this kind of push. Additionally, can anyone confirm what the proper background mode setup is for push notifications on watchOS? Is it supposed to remote-notification under UIBackgroundModes or WKBackgroundModes? For WKBackgroundModes Xcode only offers a few watch specific values, but not the push value. The docs are unclear on this part.

I understand that with the 26.4.2 patch, when you click on a notification preview to check a text message, the saved preview data is deleted. So, what should I do to delete the preview data that was left over from clicking on notification previews before the 26.4.2 patch? First of all, I don't want to do a factory reset. So I'm just want to know about this.

Excited for AlarmKit! I have found two concerns that I cannot find answers for though. The volume of my alarms seems to be very quite relative to the full volume capability of the device. For example, if I turn the volume all the way up and play the audio file, the sound is very loud. However then, if I set the alarm using alarm kit with the same audio, the track played during the alerting phase is not that loud. I am afraid that it will not be loud enough in real life. Will there be future support to set the volume level of the alarm to maximum settings? When I press the volume buttons (with the app open) during an active alarm, the audio stops, but the alarm manager does not clear these events. The alarm manager does clear the alarm event if the alarm is stopped through a live activity.

Hello, We are planning to shut down our mobile app service and need to discontinue our auto-renewable subscription product. Our service termination date is July 31, and we are currently preparing the backend implementation for this. We have reviewed the official documentation and Apple Developer Forums, but there are several behaviors we cannot confirm through sandbox testing, as the "Remove from Sale" setting does not appear to affect the sandbox environment. We would greatly appreciate clarification on the following: Server notification at the moment of "Cleared for Sale" being unchecked When we uncheck "Cleared for Sale" in App Store Connect, is any App Store Server Notification (V2) sent to our server immediately at that moment? If yes, what is the exact notificationType and subtype value sent? If no, when is the first notification triggered for existing active subscribers after this action? 2. Notification sequence from product removal through final expiration For existing active subscribers, what is the exact sequence of notificationType and subtype values our server should expect — from the moment we remove the product from sale through the subscriber's final expiration? Based on our research, we believe the sequence may be: (1) Cleared for Sale unchecked → (2) No immediate notification → (3) At next renewal attempt → EXPIRED with subtype PRODUCT_NOT_FOR_SALE Could you confirm whether this is correct, or provide the accurate sequence? 3. Whether DID_CHANGE_RENEWAL_STATUS is sent before EXPIRED Is a DID_CHANGE_RENEWAL_STATUS notification sent to our server at the moment of removal from sale, before the EXPIRED notification at the renewal date? If yes, what is the subtype of this notification? 4. Recommended server-side handling per notification For each notification in the sequence above, what is the recommended server-side action? For example: On EXPIRED with subtype PRODUCT_NOT_FOR_SALE → revoke entitlement immediately? On DID_CHANGE_RENEWAL_STATUS (if sent) → update status only, do not revoke entitlement yet? Sandbox testing limitations We have confirmed that the "Remove from Sale" setting does not affect the sandbox environment. Is there any recommended way to test this scenario before applying it in production? If sandbox testing is not possible for this case, is there any official confirmation of this limitation? We have a fixed service termination schedule and need to ensure our backend handles this correctly. Any clarification or pointers to official documentation would be greatly appreciated. Thank you.

We are so interested in AlarmKit which is presented at WWDC25. While we planning our app using AlarmKit, We had a few questions come to mind and were hoping you could provide some clarity. Please excuse the rather long list of questions, as we don't currently have a device available to test these features ourselves. System Actions Related Is there a limit to the number of alarms that can be scheduled using AlarmKit? Are alarms scheduled with AlarmKit persistent across device reboots? When an alarm is dismissed (either by swiping or pressing the power button), can our app detect this action and execute code in response? Can we control the behavior of the physical Lock Screen buttons when an AlarmKit alarm is active, for instance, to trigger a snooze action? Does AlarmKit function correctly during Do Not Disturb or Low Power Mode? What is the expected behavior when an alarm from our app (using AlarmKit) overlaps with an alarm from another app that also uses AlarmKit? Which one is going to get its priority? Thank you for your help. Sincerely

Hi all, I'm building an iOS alarm app on AlarmKit (iOS 26+) and running into reliability issues I can't find documented anywhere. Hoping someone here has insight. What we're doing We schedule a "fan-out" pattern, a single user-set alarm becomes a sequence of AlarmKit alarms firing at regular intervals over ~50 minutes. The density is needed because we require repeated wake-up alerts the user can't easily ignore until they complete an explicit dismissal action. A single AlarmKit alarm that auto-mutes after Apple's default duration doesn't solve the heavy-sleeper case. We've seen other iOS alarm apps use a similar approach reliably on iOS 26+, so the pattern seems achievable. We're clearly missing something about AlarmKit's behavior under dense scheduling. The issue AlarmKit alarms intermittently fail to enter .alerting at their scheduled times when the device is locked. Lateness varies from ~20 seconds up to 4+ minutes. The bug is intermittent ie. no deterministic reproducer. When the lateness is short (~15-22s), the next alarm in the sequence often fires only a few seconds later, suggesting the first two get bunched rather than firing independently. When the lateness is long (minutes), our AlarmManager.shared.alarmUpdates subscriber observes zero .alerting transitions during the gap, then receives a flurry of events when the device wakes. Verified via on-thread Swift logging, not a bridge or JS-suspension issue. Our setup AlarmManager.AlarmConfiguration with .fixed(date) schedule, AlarmAttributes + stop button, StopAlarmIntent, custom .named(...) sound No alerting duration specified (we don't believe one is exposed) NSAlarmKitUsageDescription set; AlarmKit authorized Registered WidgetExtension for the auto Live Activity No Critical Alerts entitlement (docs suggest AlarmKit doesn't need it) Questions Is there a documented or undocumented density limit for AlarmKit alarms scheduled in close succession? What is iOS's behavior when multiple AlarmKit alarms are simultaneously in .alerting state? Coalesce? Queue? Drop? Is there a supported way for the app to control per-alarm alerting duration before iOS auto-mutes? For locked-overnight scenarios, are there documented power-management or dasd interactions that defer AlarmKit fires? Does declaring UIBackgroundModes fetch/processing affect this? Any insight or a point in the right direction would be super appreciated!

In my VoIP app, we use StartRing and StopRing via VoIP push to my app. But recently, I found some disordered VoIP notifications, my VoIP app received the StopRing push before the StartRing push. Examples: Server log: // send StartRing startring: - Apr 9, 2026 @ 14:54:43.255 .."pushType":"voip","priority":10, ... // send StopRing stop-ring Apr 9, 2026 @ 14:54:47.645 ..."pushType":"background","priority":5,"... VoIP app log: // receive StopRing 2026-04-0909:54:48.858 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StopRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 // receive StartRing 2026-04-0909:54:49.524 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StartRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 Then we can see the StartRing send first, but received in the app after the StopRing. The StartRing took abunt 6s to send and the StopRing took about 1s. So I guess there is an issue in the APNs part on iOS26.4. We saw there is a peak after iOS26.4 and iOS 26.4.1 than old iOS versions. Thanks.

I have a VoIP app, now try to implement the new method which support the "PKVoIPPushMetadata" in iOS 26.4. Code as below: /// iOS 26.4+ (SDK with `PKVoIPPushMetadata`): prefer this path for VoIP per Apple; completion is `@Sendable` on supported SDKs. @available(iOS 26.4, *) func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingVoIPPushWith payload: PKPushPayload, metadata: PKVoIPPushMetadata, withCompletionHandler completion: @escaping @Sendable () -> Void) { print("willtest: didReceiveIncomingVoIPPushWith: metadata=\(metadata)") handleVoIPPush(payload: payload, metadataMustReport: metadata.mustReport, completion: completion) } func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { print("willtest: didReceiveIncomingPushWith: PKPushType=\(type)") handleVoIPPush(payload: payload, metadataMustReport: nil, completion: completion) } But the voip push only goes to the old method on my iOS26.4 device(iPhone17). And it will go to the new method after I delete the old method. So how can I use this method in my app? I must support iOS16+ versions.

Hi, Quick question on AlarmKit (iOS 26): is there any way to disable the vibration/haptics that play alongside the alarm sound? I'm building a gentle wake-up alarm and I'd like sound-only behavior. From what I can see, AlertConfiguration.AlertSound only lets me customize the audio (.default or .named(_:)). There doesn't seem to be a haptic-related property on AlertConfiguration or anywhere else in the alarm configuration chain. Is this a current limitation, or am I missing something? If it's a limitation, I'll file a Feedback Assistant request and post the FB number here. Thanks!

Hello, We are experiencing an issue related to push notifications after updating devices to iOS 26.4 Beta. Our system stores push notification tokens on the server by associating the device token with the device’s IDFV in the app. After updating a device to iOS 26.4 Beta, we observed that the device token from a previously uninstalled version of the app remains valid for more than a week. As a result, two push notifications are delivered to the same device. The situation is as follows: The user installs the app and a device token is generated. The user uninstalls the app. Later, the user installs the app again and a new device token is generated. However, the previous device token does not become invalid, even after more than a week. Because IDFV changes when the app is reinstalled, our server cannot determine that the device belongs to the same user. Therefore, we cannot overwrite the old token with the new one on the server side. Could you please advise: Is this behavior expected in iOS 26.4 Beta? How long does it normally take for a device token to become invalid after an app is uninstalled? What is the recommended approach to prevent duplicate push notifications in this situation? Any guidance would be greatly appreciated. Best regards