Hello, I submitted a couple of requests with justification for NSE filtering on an app of mine, but I have not received correspondence on either. The initial ticket is RY24AB5J5T, if anyone who reviews them happens to see this post. Happy to hop on a call, exchange emails, or anything else that may be required to process it toward a conclusion. 🙂

We're looking for clarification on how APNs enforces provider authentication token update limits across independent HTTP/2 connections. We operate a production APNs sender using ES256 JWT-based authentication. The sender: Signs a provider JWT using an APNs authentication key. Caches and reuses that JWT for approximately 50 minutes. Opens a new HTTP/2 connection to api.push.apple.com for each notification, then closes it after receiving the response. We want to perform a single-notification delivery test from a separate, short-lived process using the same Production APNs environment. Our concern is avoiding any disruption to the existing production sender. Apple's token-based connection documentation states that using a new authentication token too frequently can cause errors "on the same connection" and that "You can use the same token from multiple provider servers." The APNs response documentation also describes HTTP 429 TooManyProviderTokenUpdates. Questions Throttle scope: Is TooManyProviderTokenUpdates enforced strictly per HTTP/2 connection, or can it apply across connections sharing the same signing key, Apple Developer team, topic, or Production environment? Independent JWT signing: If our test process signs a fresh provider JWT using the same APNs key and sends one notification over a new HTTP/2 connection, could that cause throttling for our production sender, which continues using its previously cached JWT on separate connections? Separate signing keys: Would using a different APNs authentication key under the same developer team isolate token-update throttling, or could limits still be shared at the team or topic level? Recovery behavior: If APNs returns TooManyProviderTokenUpdates, how long does the restriction last? Can existing valid tokens on other connections continue working? Could continuing to send requests with an unchanged cached JWT prolong the restriction? Recommended approach: For a one-time delivery test alongside a production sender, is it preferable to reuse the existing cached JWT across processes rather than independently sign a new one? We have not executed the test because we want to understand the potential impact on production push delivery first. Any guidance from Apple engineers on the enforcement scope, recovery behavior, or recommended testing procedure would be appreciated. Thank you!

The company I work for sends large amount of traffic to APNs on behalf of our customers, with rates up to 50k/second at peek times. While a vast majority of the messages are successful or return a proper error code that we can parse and honor, roughly 1.5 million times per day our connections are being closed without warning. The networking library we use, https://github.com/hyperium/h2, is exposing these as ErrorKind::ConnectionReset or ErrorKind::BrokenPipe. From our reading of the APNs documentation, it is unclear what the correct response is when this occurs. There is no idempotency key included with our messages, so attempting to resend the message again seems frought with the potential for double sends. However, it some cases it seems clear that at least some of the messages in flight over that connection where never sent out at all. We found this open source project unconditionally retrying messages in this case. https://github.com/rpush/rpush/pull/734 Could someone from the APNs team please lay out the expected behavior a client should have when our connection is unexpected closed in this manner?

We build an internal on-call pager app for our engineers, distributed through TestFlight only. Our server sends a heartbeat push to each device every 4 hours. The Notification Service Extension uses it to re-arm a dead-man's-switch alarm on the device: if heartbeats stop arriving, the alarm goes off and the engineer knows the paging pipeline is down. The heartbeat has to be an alert push with mutable-content, because that is the only push type that reliably launches the extension, including when the user has swiped the app away. Background pushes don't work here: they are throttled and are not delivered to an app the user has force-quit, so the dead-man alarm would fire falsely. The problem is that every heartbeat leaves an entry in Notification Center. It carries nothing actionable, and it teaches on-call engineers to ignore notifications from a pager app. Real alerts are always shown, and the extension still shows a visible notification when a heartbeat detects a problem (missed alerts, failure to re-arm). We already send heartbeats with interruption-level passive and an apns-collapse-id, so it is a single quiet entry, but it is still there. com.apple.developer.usernotifications.filtering would solve this exactly. However, the request form requires picking one of four use cases (end-to-end encrypted messaging, earthquake warnings, education alerts, healthcare alerts), and ours is none of them. An earlier reply on this forum said other use cases are welcome to apply (https://developer.apple.com/forums/thread/676672), but the form no longer offers a way to describe one. Questions: Can an app whose use case is outside the four listed apply for the entitlement? If so, how should we fill in the required use-case field? If not, is there a supported way to have an alert push launch the extension without leaving an entry in Notification Center? For example, is it supported for the extension to remove its own delivered notification with removeDeliveredNotifications(withIdentifiers:) after calling the content handler? Thanks!

We're building a SaaS that lets independent businesses issue Apple Wallet stamp-card passes. Our server signs every pass with a single Pass Type ID from our developer account. Each pass shows the merchant's own name and branding, and the back says "Issued by our platform" with a support contact. Updates use the standard web service plus an empty APNs push. Two questions: 1. Is it acceptable for one Pass Type ID to issue passes for many independent merchants, or should each merchant have its own? If a merchant sent abusive promotions, could Apple revoke the shared Pass Type ID and affect all merchants? 2. We use changeMessage on a back field to show merchants' occasional promotions (max one every 48 hours, reviewed by us), as well as on stamp and reward updates. The Wallet HIG discourages changeMessage for marketing. Is a promotional message on a loyalty pass acceptable, and what's the recommended mechanism? Has anyone running a multi-merchant platform dealt with this? Thanks!

Hello, We are I am reviewing an app-controlled icon-badge design for my app using UNUserNotificationCenter.setBadgeCount. This is a design question, not a reported device failure. Real-device badge testing and activation remain pending. We need to understand this sequence: App process A issues a badge update but terminates before receiving its completion callback. App process B starts later, calls setBadgeCount(0), and receives successful completion. The app may subsequently set a new badge count for new activity. Could you clarify: Does process B’s successful zero update guarantee that every badge request from process A has finished or been discarded, so none can change the badge later? This includes an old zero request that could erase a newer count. When a setBadgeCount completion handler reports an error, is that particular operation finished, with no further badge-value change possible from it? We are not assuming that an error means no change occurred. If a new-process zero does not provide the guarantee in question 1, is there a supported public API to cancel outstanding badge operations or establish that all earlier operations have finished before new badge updates resume? Please identify any relevant documented guarantees and the iOS versions they cover. Our proposed design uses one coordinator for local badge writes and does not include automatic remote badge numbers. Thank you, Adrian

My app was approved and released on the App Store on Aug 19, 2026 (bundle ID br.com.stackads.app, Team ID MSGM29Z362). Push notifications do not work on the production/App Store/TestFlight build. Android via FCM works fine; only iOS production APNs fails. It has been more than 48 hours since release. I captured the raw APNs device token directly from application(_:didRegisterForRemoteNotificationsWithDeviceToken:) in a production (App Store distribution) build (aps-environment = production, verified in the built .ipa entitlements). Sending directly to APNs with a token-based .p8 auth key (Key ID VXXXXXXX, Team ID MSGM29Z362), apns-topic br.com.stackads.app, apns-push-type alert, returns: api.push.apple.com (production): HTTP 403 {"reason":"BadEnvironmentKeyInToken"} api.sandbox.push.apple.com (sandbox): HTTP 400 {"reason":"BadDeviceToken"} The provider (JWT) authentication succeeds (I get a device-token error, not an auth error), so the key is valid. The App ID has the Push Notifications capability enabled. The token is freshly registered (confirmed identical between the didRegister callback and getAPNSToken). Why does the production APNs endpoint reject a valid production device token for this App ID with BadEnvironmentKeyInToken? Is there something pending in the production APNs provisioning for a newly released App ID?

I am testing a native AlarmKit prototype on a physical iPhone running iOS 27.0.1. The current build uses Xcode 26.6 / iPhoneOS SDK 26.5; a separate successful CI inspection of Xcode 27.0 / iPhoneOS SDK 27.0 found no alerting-timeout or expiry parameter. I use public APIs only. Normal scheduled alarms, manual Stop, and user-triggered countdown snooze work while the phone is locked. A bundled 10-second custom WAV plays, but audible alerting continued beyond 15 seconds until manually stopped. I understand that preAlert/postAlert are countdown intervals and that a sound file's length is not an alert timeout. Is there a supported system-owned setting or architecture to end audible alerting after a configurable duration (for example 10 or 11 seconds), without user interaction, while the app is suspended or not running? If supported, can that timeout transition into another alarm/countdown after a configurable interval, with a bounded repeat count, while Stop cancels the remaining opportunities for the same occurrence? I have not found a documented maximum alerting-duration parameter. I am not seeking a Timer, Task.sleep, background-refresh timing assumption or ongoing background-audio workaround. Preregistering multiple alarms also raises overlap and cleanup issues. If cancellation of preregistered sibling alarms from stopIntent is recommended, what execution guarantees apply when dismissal is via the system Stop UI or a physical button, particularly after reboot before the first unlock? Does AlarmKit provide an atomic system-owned alternative to scheduling the next alarm and then stopping the current one? Please distinguish documented behavior from a best-effort approach. Guidance on whether these requirements need an enhancement request would be helpful.

On a physical iPhone running iOS 27.0.1, an AlarmKit alarm due while the device was powered off sounded immediately after restart, approximately two minutes after its deadline, before the first passcode entry or app launch. We observed this with both fixed(Date) and relative hour/minute with repeats: .never. A normal control rang on time. Inspection of the public AlarmKit interface in iPhoneOS SDK 27.0 found no expiry parameter. Is this overdue replay expected? Is there a supported validity window or guaranteed pre-presentation mechanism that suppresses expired opportunities while retaining valid future opportunities? Cleanup after app launch is too late. Should this be filed as a bug or enhancement request?

We make a messaging and calling app (Call.com). When a user reads a chat on another device (web or another phone), we want that chat's notifications removed from their iPhone's lock screen and Notification Center. Our plan is a Notification Service Extension that receives a "message read" push, removes the matching delivered notifications with removeDeliveredNotifications(withIdentifiers:), and then hides the read push itself by passing an empty UNNotificationContent to the content handler. The read push carries only a conversation ID and a message ID, with no message content. Hiding it needs com.apple.developer.usernotifications.filtering. The entitlement request form offers four use cases. The closest is end-to-end encrypted messaging, but it doesn't apply to us: our server can read notification content. So we don't think we should select it. We tried a background push (content-available: 1, sent through FCM) first. We tested on a physical iPhone with Background App Refresh on and the app running in the background (not force-quit). The device log showed the push being deferred: a com.apple.pushLaunch.<bundleId> activity was submitted with a 24-hour window. A second background push sent about 190 ms later cancelled that pending activity. The app never ran, and the notification stayed on the lock screen for the 8 minutes we watched. Questions: Can the filtering entitlement be granted for this use case, or only for the four listed ones? If not, what is the recommended way to remove delivered notifications after the user reads them on another device? Is a background push the only supported option? If a background push is the answer, what can we do to make it more reliable? For example, would sending one background push per read event instead of two help? Thanks!

Hello, We are investigating an intermittent production VoIP push issue involving Twilio, PushKit, and CallKit. For one incoming call, an iPad registered to the same Twilio identity received the VoIP push and successfully reported the call to CallKit. An iPhone had no corresponding native push-received, call-invite, or CallKit reporting events. The iPhone successfully received, displayed, and answered calls both before and after the affected call. Twilio engineering has confirmed the APNs ID and its association with the affected iPhone device token. We have the exact UTC timestamp, app/device versions, provider correspondence, and a client event timeline. We can provide these through a private channel. There is also a client logging gap around the incident, so we are not treating missing client events as proof of APNs non-delivery. We would like to determine whether APNs received the specific request, attempted delivery, and has any delivery outcome information available. We do not have a focused sample Xcode project that reproduces this historical incident. Selecting No for that question in the code-level support request form directs us to the forums. Could an Apple engineer advise: How can we request a private APNs delivery investigation using the provider-confirmed APNs ID and timestamp? Is there an appropriate support or Feedback Assistant route for a production incident without a reproducible sample project? Which additional provider records or device diagnostics should we collect? We have omitted device tokens, request identifiers, and detailed logs from this public post and can supply them through an appropriate private channel. Thank you.

Hello, We develop Barra, an order-ahead pickup app in Saudi Arabia built to support productive families: small home-based businesses, mostly women cooking or making handmade products from home. Customers order from them in our app and collect the order from their car. The families depend on one notification: when a customer places an order, the family's iPhone receives a "New order" push with our own sound. They have a few minutes to accept it before it is cancelled automatically, so hearing that sound is how they earn their income. The problem: families report that this notification sometimes plays its sound and sometimes arrives silently — same iPhone, same settings, ring/silent switch off. Our server logs show every push is sent and accepted by APNs (via Firebase Cloud Messaging) and the notification itself appears. Only the sound is sometimes missing. We are not trying to bypass the silent switch and we are not asking for Critical Alerts. If a family puts the phone on silent, we respect that. The sound only goes to merchant devices, only for a real customer order (plus at most one reminder per minute while the order is still waiting). Our setup Headers: apns-push-type: alert, apns-priority: 10, an apns-collapse-id per order aps: alert {title, body}, sound: "bra_order_alert.caf", badge: 1, interruption-level: "time-sensitive" bra_order_alert.caf: IMA4, 44.1 kHz, 16.4 s, in the main bundle Foreground: willPresent returns banner + badge + sound Our next build adds the Time Sensitive Notifications entitlement (it was missing before) iPhones on iOS 18.x, 26.x and 27.0 Questions Which conditions can make iOS deliver an alert push silently while the silent switch is off? For example notification summary, Focus, several notifications close together, Apple Watch or Bluetooth audio routing, replacing a notification with the same apns-collapse-id, the sound file's length or format, or the app's own audio session. Is there anything in our payload or sound file that could make the sound play only some of the time? When a notification replaces an earlier one with the same apns-collapse-id, does iOS play the sound again? What do you recommend for merchant apps so order notifications are reliably audible, while fully respecting the silent switch? Filed as FB25199572. Thank you!

Spent a good while debugging my own alarm code before working out the problem wasn't mine, so here it is in case someone's about to do the same thing. iOS 27 simulator, erased, clean install. requestAuthorization() comes back .denied and you never get a permission dialog at all. I had XCUITest sitting there watching SpringBoard for an Allow button over a bunch of runs, nothing. You can grant it manually in Settings and then authorizationState says .authorized, so the permission itself works, it's just the prompt that doesn't happen. On my actual phone (13, same 27.0) everything's normal, it schedules and rings and the alert comes up with snooze and stop on it. Then I went back to a 26.3 sim to compare and that one's worse here. SpringBoard keeps crashing, every few minutes, same thing each time: -[TLAlertQueuePlayerController _prepareAudioEnvironmentForStateDescriptor:isForMusicPlayback:] Unrecognised selector, SIGABRT, while it's trying to play the alert tone. It did that on a device I'd just erased with my app not even installed yet. Has anyone got the AlarmKit prompt to show up on 27 at all? Flag, particular device, entitlement, something in the plist I'm missing? And if you did grant it by hand there, do alarms actually fire afterwards on the sim? I never got far enough to find out, I just moved to the phone. Also curious whether anyone else sees that ToneLibrary crash on 26.3 under macOS 27. The AlarmKit wrapper I was poking at when I hit this is a free MIT gist, auth handling and deterministic alarm ids and the cancel-then-schedule ordering that got me earlier in the week: https://gist.github.com/yakubmurcek/61d8e3a60eb81e2c1f785010b4aa46de

Hi, I'm developing an iOS 26+ app using Apple's AlarmKit and App Intents. I want to implement a prominent reading alarm with the following behavior: The AlarmKit alarm starts at a scheduled time. The alarm should remain actively alerting for a limited duration (for example, up to 60 seconds). The alarm has a custom secondary action such as "Start Mission". When the user taps "Start Mission", the custom App Intent should immediately stop/silence the alarm and open the app. If the user does not interact with the alarm, it should automatically stop after the maximum duration. I do NOT want to repeatedly schedule/re-ring multiple alarms every 20–30 seconds. I am using only public AlarmKit APIs and App Intents. My main question is: Is AlarmKit designed to support this behavior — specifically, keeping a prominent alarm actively alerting for a defined maximum duration (e.g. 60 seconds), while allowing a custom App Intent to stop it earlier? If this is possible, what is the recommended public AlarmKit API/configuration for controlling the maximum active/alarming duration? Also, does AlarmKit provide any official way to control when an alarm automatically stops, or is the duration entirely managed by the system? I'm trying to follow Apple's intended AlarmKit architecture and avoid private APIs or unsupported behavior. Thanks!

Hello, We are investigating intermittent push notification delivery issues for a production iOS application. Our push architecture is: Application backend → Firebase Cloud Messaging (FCM HTTP v1) → APNs → iOS devices During a recent large-volume notification event, some iOS users reported not receiving the notification, while many other users successfully received the same type of notification during the same period. From our sending platform: The affected notification requests were successfully accepted by FCM. No sending error was returned for the affected cases. The FCM registration tokens of the affected users were verified and were not invalid or unregistered. We then reviewed the production metrics in Apple Push Notifications Console. For a recent one-week period, the console reported approximately: Received by APNs: 729.7K Delivered to Device: 553.5K Delivered to Device (From Storage): 125.2K Stored - Device Offline: 58.4K Stored - Power Considerations: 5.7K We understand that these status counts represent status occurrences and are not necessarily mutually exclusive. For example, the same notification may first be stored and later delivered from storage. However, we would like to better understand the relatively large number of notifications being stored by APNs. Could Apple please clarify: What device or APNs conditions specifically cause a notification to be classified as Stored - Device Offline? What conditions cause Stored - Power Considerations for normal user-visible alert notifications? For an application with a large production user base, are these volumes or proportions considered normal APNs behavior? When a notification is stored because the device is offline or because of power considerations, under what circumstances can it eventually fail to reach the device? If multiple notifications for the same application/device arrive while the device is unavailable, can an earlier stored notification be replaced or discarded by a newer notification? Because our APNs provider connection is handled by FCM, we do not currently have the APNs ID for each individual request. Is there another Apple-supported way to investigate an individual production notification, or correlate it with the Push Notifications Console delivery data? Are there any recommended APNs configuration or sending practices that could reduce the number of notifications entering these stored states? We can provide exact UTC timestamps, Push Notifications Console screenshots, exported metrics, and additional production information privately if an Apple engineer needs them. Thank you.

We are considering developing an iPhone application for workers operating in environments where safety is critical and notifications may involve life-threatening situations. We understand that Apple's Critical Alerts feature can deliver notifications with audible alerts even when the device is muted or Focus mode is enabled. However, we would like to know whether it is possible for a third-party app using Critical Alerts to present an emergency alert directly on the screen in the foreground, similar to the way iOS displays government-issued emergency alerts such as Earthquake Early Warnings (EEW). Specifically, can a third-party application trigger a full-screen emergency alert that immediately appears over other applications, rather than relying solely on a notification banner and alert sound? If this is not possible, are there any Apple-supported mechanisms or APIs that allow life-safety applications to provide a comparable user experience for urgent emergency notifications? We would appreciate any clarification regarding the capabilities and limitations of Critical Alerts for life-safety use cases.

Environment: iPhone 17 Pro, iOS 27.0, Xcode 27, dev build (aps-environment development), sandbox APNs, token-based auth. The app uses the PushToTalk framework with one restored channel; audio is WebRTC, started only after didActivate. Push headers: apns-push-type pushtotalk, apns-topic .voip-ptt, apns-priority 10, apns-expiration 0. Payload about 460 bytes. APNs returns 200 to every push in about 250 ms. What we then see is after a pushtotalk push is delivered and handled, the next push sent about 6 to 7 minutes later is not delivered to the app (no incomingPushResult call), although APNs returned 200. Pushes sent about 13 or more minutes after the last delivered one are almost always delivered. Overnight automated runs, phone on power, Focus off, no calls. Pushes sent after a delivered push: 38 of 38 lost (one run), 31 of 32 lost (another run). Pushes sent about 13+ minutes after the last delivered push: 38 of 40 delivered, and 37 of 41 in the other run. Lost pushes are not late: none arrived within 5 minutes after sending. What we ruled out: App state: the loss is the same whether the woken app is terminated about 37 s after the push or left to suspend on its own, and whether or not it sets activeRemoteParticipant to nil when the remote audio ends (the audio session deactivates in that case). Push token: the server's token matches the token the app last received. Focus and calls: Focus off, and pushes near calls were excluded. Separately, pushes sent within the first few minutes after the app is launched (by hand or by devicectl) are also mostly lost. Questions: Is there a limit, documented or expected, on how often the system delivers pushtotalk pushes or wakes the app after a recent incoming push? Could apns-expiration 0 cause these pushes to be discarded, for example if the device is briefly unreachable after a Push to Talk wake? Is a short non-zero expiration appropriate for pushtotalk? Is this expected in the sandbox environment, and would production behave differently? Beyond setting activeRemoteParticipant to nil when the remote speaker stops, should the app do anything after handling an incoming push so that the next push is delivered? We can share log excerpts or a sysdiagnose on request.

Dear Apple Developer Support, I am developing HushRise, an iPhone alarm application intended to help people in Ukraine manage sleep disrupted by wartime air-raid alerts. Nighttime alerts can force people to interrupt their sleep and seek shelter, sometimes repeatedly. Families must then plan work, school, and other responsibilities around these disruptions. Educational institutions and other services may suspend in-person activities during alerts, making a fixed wake-up time less useful than a wake-up signal that takes the current alert status into account. The purpose of HushRise is to support rest and daily routines under these conditions. It is not an official emergency-warning service and must not replace civil-defence alerts or encourage people to ignore them. The intended behavior is: A user sets a wake-up time and selects their region. At that time, the alarm starts only after a fresh server response confirms that no air-raid alert is active. If an alert is active, the application waits for the reported all-clear. Multiple alarms postponed during the same alert should produce one wake-up signal after the all-clear. A snoozed alarm must also obtain fresh confirmation before starting again. An alarm that has already started may continue until the user stops or snoozes it. We have tested a native AlarmKit integration on a physical iPhone. The system alarm, Lock Screen controls, Apple Watch presentation, and Stop action work. However, without ongoing background audio, iOS suspends our application’s status checks. In one test, an alarm due at 20:09 was not scheduled until the application returned to the foreground at 20:11. Audible background playback helped in experiments, but requiring continuous sound is not appropriate for the intended quiet sleep experience. Could your technical team please advise: What supported architecture should we use for an AlarmKit alarm whose trigger depends on a server event occurring at an unknown time? Can a server notification initiate the necessary validation and alarm scheduling while the iPhone is locked, and what execution guarantees or limitations apply? Is there an entitlement or approval process appropriate to this use case? Would Critical Alerts be applicable, or would another mechanism be more suitable? Which capabilities require Apple Developer Program membership? Our current prototype is installed through a free Personal Team. We understand that an offline device cannot receive new server information and that notification delivery may be delayed. We want to communicate these limitations honestly and build within Apple’s supported APIs. We can provide a minimal reproducible project, sanitized device logs, and a description of our physical-device tests. Thank you for helping us identify a reliable and appropriate approach for people whose sleep and daily lives are affected by the war in Ukraine. Kind regards, HushRise developer

If you submitted a request for a Critical Alert Notifications entitlement and did not receive a response, please resubmit your request.

Hello, I'm developing an iOS voice alarm app. Is there a supported public API that can launch or resume app code when an AlarmKit alarm fires, so it can announce the current time while the phone is locked, without user interaction or an internet connection? The announcement needs to reflect the time playback actually begins, including when an alarm is delayed. Pre-generated audio would also work if the app can select the correct recording at playback time. My prototype subscribes to AlarmManager.shared.alarmUpdates at app startup and attempts speech when the alarm becomes .alerting. This works in the foreground, but in background trials no speech attempt occurred before reopening the app. These trials did not test termination by iOS or user force-quit. Could you clarify whether this use case is supported when the app is suspended, terminated by iOS, or force-quit by the user? If so, which API should I use? If not, could you confirm the limitation or suggest a supported alternative? Test environment: iPhone 13, iOS 26.6.1 (23G83), Xcode 26.6, iPhoneOS 26.5 SDK; release build without a debugger attached. Thank you for your guidance.