When attached app to debugger with real device, the OS seems to kill the app if the Callkit interface isn't emitted by the app at background within 5s. Do you have any tip in debugging?

"The introduction of team-scoped keys is a fantastic step forward for tightening security and isolating responsibilities within larger development organizations. However, as infrastructure moves closer to Zero Trust architectures, managing these keys across decentralized microservices or CI/CD pipelines still presents challenges. I have two questions regarding the long-term roadmap for APNs authentication: 1 App-Level Scoping: Are there plans to allow authentication keys to be scoped down to specific App IDs (Bundle IDs) rather than the entire team? Currently, a compromised team-scoped key could still potentially impact other apps within the same developer account. 2 Short-lived / Ephemeral Tokens: Is Apple considering support for short-lived, dynamically generated authentication tokens (similar to AWS IAM roles or OAuth 2.0 client credentials with expiration) to eliminate the need for storing long-lived ⁠.p8⁠ master keys on third-party backend servers? Understanding the direction of APNs security would greatly help us architect our next-generation notification backend."

Years ago a notification evangelist had recommended supporting NotificationContentExtension and NotificationServiceExtension. Fast forward to notification AI summaries, live activities, and lock screen widgets, iPhone mirroring, and all the others I'm missing, are there any other features developers should be utilizing when building out a notification strategy? Conversely, are there things to look out for if we DON'T adopt something as a negative? For context, the notifications might be general all audience, as well as, direct to user with custom content.

When updating Notifications, is it best practice to delete and reset all of them, or just delete and reset the Notifications that need to change? We have data coming from multiple sources, and as a result, we are often updating the notifications. This can be several times in under 10 seconds.

We have an emergency alert app that can trigger alarms in the event of a potential accident. We currently use Critical Alerts, which works well when the app is suspended or running in the background. A key requirement is that the alarm continues playing until the user explicitly acknowledges or dismisses it, as nearby people may need to notice the alarm and assist. Today, we’re achieving this by scheduling multiple Critical Alert notifications with the maximum sound duration (30 seconds) to create a longer continuous alarm. While this mostly works, it feels like a workaround and isn’t fully reliable. Is there a recommended way to implement a persistent emergency alarm experience on iOS? Would AlarmKit be an appropriate solution for this use case, or is it intended only for user-scheduled alarms and timers? Are there any other APIs or patterns you would recommend?

Will your team consider adding an app delegate or notification center delegate to let apps know the system notification permission enable and disable change?

How far in advance can you register a live activity with an app using the remote notification support mechanism? Is this consistent across OS versions and device models? Any gotchas to be aware of when expanding to live activities and their supporting notifications in terms of update frequency or APNs dropping pushes if they queue up?

Populating widgets with silent push notifications would be great for us if they were more predictable. Can you share tips for debugging / testing in Test Flight beyond the usual recommendations available online? When messages are not processed it is a major challenge to distinguish between code problems and device throttling.

Populating widgets with silent push notifications would be great for us if they were more predictable. Can you share tips for debugging / testing in Test Flight beyond the usual recommendations available online? When messages are not processed it is a major challenge to distinguish between code problems and device throttling.

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!

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!

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

I'm building a macOS app and trying to confirm whether there's a way for me to remotely wake a Mac so my app can do a small amount of work (using APNs silent notifications or any other technique). Here's what I want to happen: User runs my app on their Mac User puts the Mac to sleep (Apple menu > Sleep) 30 minutes later, my server sends a push notification (content-available: 1, apns-push-type: background, apns-priority: 5) via APNs to the Mac Note: Power Nap and Wake for Network Access are enabled The Mac dark-wakes, delivers the notification to my app via application(_:didReceiveRemoteNotification:), my app gets ~30 seconds to open a WebSocket, do some work, and return Mac goes back to sleep So far, I've been able to send silent push notifications to a sleeping Mac, but my app only gets to take action on them after the Mac has been awoken manually. I've tried both silent pushes (content-available: 1, priority 5) and alert pushes (priority 10) with the same result. After trying every option I can find, I don't believe notifications can wake a sleeping Mac and allow my third-party app to process data, but I really want to be wrong. Can anyone confirm whether or not this is possible?

NSE Filtering Entitlement — No Response After 4+ Weeks (Request ID: 7NPNCB7Q9P) We submitted a request for the Notification Service Extension Filtering Entitlement (com.apple.developer.usernotifications.filtering) over two weeks ago and have received no response. App: NoLink Bundle ID: io.nolink.ios NSE Bundle ID: io.nolink.ios.nse Team ID: V2E3A94DC9 Request ID: 7NPNCB7Q9P Support Case ID: 102886799629 NoLink is an end-to-end encrypted messaging app built on the Matrix protocol with voice and video calling. All push notifications arrive encrypted — the NSE decrypts them to determine if the event is a message or an incoming call. Without this entitlement, incoming VoIP calls cannot ring properly. Users receive a silent text notification instead of the native CallKit incoming call screen. The duplicate APNS notification for call events cannot be suppressed. Element X iOS (io.element.elementx) has been granted this exact entitlement for the identical use case — same Matrix protocol, same Matrix Rust SDK, same NSE architecture. NoLink is built on the same codebase. We also opened Support Case 102886799629 but received only a generic response directing us to the Developer Forums. Could someone from the Entitlements team please review our request? We are happy to provide any additional technical details or a demo. Thank you.

I’m trying to diagnose an APNs provider authentication issue that began after APNs had previously been working. Summary: My iOS app can register for remote notifications and successfully sends its device token to my server. The app has the Push Notifications capability enabled in Xcode, the Bundle ID has Push Notifications enabled in Certificates, Identifiers & Profiles, and the APNs key is active in the Apple Developer portal. However, every server-side APNs send attempt now fails with: HTTP 403 {"reason":"InvalidProviderToken"} This happens against both sandbox and production APNs endpoints. App / account details: Bundle ID / apns-topic: app.terrasignal Team ID: 837F2XGDX Current APNs Key ID: HNW7XPK2H3 APNs key type: Apple Push Notifications service (APNs) Key configuration: Team scoped, Sandbox & Production Xcode signing team: David Buck / Team ID 837F2XGDX Push Notifications capability is enabled in Xcode Device token environment tested: sandbox Server clock verified against Apple/date header and matches UTC What works: iOS app launches successfully Push permission is granted Device token is generated Device registers with my server successfully Server stores the token as sandbox for bundle app.terrasignal What fails: Server-to-APNs provider authentication Direct HTTP/2 APNs request fails before notification delivery Failure reason is always InvalidProviderToken I tested three separate APNs keys: 34T746MWFV T9N75GU2AV HNW7XPK2H3 Each key was downloaded from the Developer portal, uploaded to the server, verified as a valid .p8 private key, and used with its matching Key ID. All produce the same InvalidProviderToken result. I also bypassed my APNs library and tested direct HTTP/2 + JOSE JWT signing. The direct APNs test also fails with the same response: HTTP status: 403 Response body: {"reason":"InvalidProviderToken"} Example direct APNs test details: Host: api.sandbox.push.apple.com Path: /3/device/ apns-topic: app.terrasignal apns-push-type: alert apns-priority: 10 JWT header: {"alg":"ES256","kid":"HNW7XPK2H3"} JWT payload includes iss: 837F2XGDX and current iat Key imports successfully with jose importPKCS8 JWT is generated successfully APNs rejects it with InvalidProviderToken I also tried production endpoint with the same result: Host: api.push.apple.com HTTP 403 {"reason":"InvalidProviderToken"} Things verified: System clock is correct Docker/server UTC time matches Apple Date header Bundle ID topic is app.terrasignal APNs key exists in the Apple Developer portal APNs service is enabled on the key Key is configured for Sandbox & Production Push Notifications capability is enabled for the app Xcode signing uses the same team The .p8 file is not empty or malformed The key imports successfully via jose/importPKCS8 The issue occurs before APNs evaluates the device token, because authentication fails first Question: What Apple-side account/key/app configuration state can cause multiple active APNs auth keys for the same team to return InvalidProviderToken, even when: the key is active, APNs is enabled, the Team ID matches, the Bundle ID topic matches, the server clock is correct, and a direct HTTP/2 APNs request with manually generated ES256 JWT also fails? Is there a way to force-refresh, repair, or re-sync APNs provider authentication for a Developer account / Bundle ID / APNs key?

Hi Team We are building a live activity feature for our app. While using the APNS broadcast API (https://api.push.apple.com:443/4/broadcasts/apps/), we are getting throttled. The updates are infrequent (sport games) and yet we are facing this issue. Our understanding was that the throughput is quite high but there is no documentation on the actual limitations. Furthermore, all of our updates are using a priority of 5. We have currently configured retry with exponential backoff and jitter but we would like to understand the APNS throttle limit for live activity broadcast. Is the limit per channel id or at API level? What is the hard limit for the API request per seconds? Can we request increase to the API rate limit?

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.

1. Does the "important" description for silent notification in the documentation still valid? (Pushing background updates to your App) The system treats background notifications as low priority: you can use them to refresh your app’s content, but the system doesn’t guarantee their delivery. In addition, the system may throttle the delivery of background notifications if the total number becomes excessive. The number of background notifications allowed by the system depends on current conditions, but don’t try to send more than two or three per hour. I would like to implement notification that would wake up my application in all state to perform AVSpeechSynthesizer, but I am confused with the availability of the silent notification. I attempted to send silent notification to my ipad to see the exact behaviour, but it seems like it has not been throttle even after a few tens attempts within the same hour. { "aps": { "content-available": 1, "alert": { "title": "Title", "body": "Content"}, "sound": "default" } } 2. I am also confused if mixing the "content-available" key pair with "alert" in the aps payload will make the Heads-up Notification been throttle as well?

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.