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!

We ship two iOS apps from the same team that are designed to work together: App A – uses CloudKit container "Container A" App B – uses CloudKit container "Container B" Until App B version 1.5, App B also had Container A in its com.apple.developer.icloud-container-identifiers entitlement, because it read a few records from App A's container directly. App B called registerForRemoteNotifications() for its own container's subscriptions. App A creates a CKDatabaseSubscription on the shared database (and CKQuerySubscriptions on the private database) with notificationInfo.alertBody set, so that a participant gets a visible push when the owner shares something. Problem: on devices where App B 1.5 (or earlier) had run, every push generated by App A's subscriptions is delivered to both App A and App B. App B shows a banner with App A's alert text under App B's name. This still happens after we shipped App B 1.6, which removed Container A from App B's entitlements entirely (App B 1.6 never touches that container). What we have tried on an affected device, none of which stopped the deliveries to App B: Updating App B to 1.6 (entitlement removed). Deleting App B and reinstalling it from the App Store. In App B, calling unregisterForRemoteNotifications() and then registerForRemoteNotifications() again on next launch. Rebooting the iPhone. Devices that installed App B 1.6 fresh (never ran 1.5) do not receive these pushes, so the behavior seems to come from a registration that was created while App B still had the entitlement and that is not being cleaned up. Questions: Is the association "APNs token of App B ↔ Container A" kept on the CloudKit server side, and is there any way for the app (or for us as the developer) to remove it once the entitlement is gone? If it cannot be removed explicitly, does it expire? Roughly how long after the app stops registering for that container? Is there a recommended way to design this (two apps, one container) so that alert pushes from one app's subscriptions are not shown by the other app? We would rather not switch App A to content-available pushes with local notifications, because silent pushes are not delivered reliably when the app has been force-quit. Environment: iOS 26, App A 4.7.x, App B 1.6.x, Production CloudKit environment. We have also filed a DTS request with the actual identifiers and can provide device logs or a sysdiagnose if helpful. Thank you.

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

Hello, I'm encountering an issue with UNLocationNotificationTrigger in my iOS app. I've scheduled three local notifications using UNLocationNotificationTrigger, each tied to a distinct geographic region. These regions are significantly distant from one another and should not trigger simultaneously under normal movement conditions. However, during testing, the user received all three notifications within one second, despite being physically located near only one of the regions. This behavior is unexpected and defeats the purpose of using location-based triggers. Could you please clarify why this might be happening? Is there a known issue with UNLocationTrigger, or is there a possibility that iOS preemptively triggers all scheduled location notifications? Any guidance or recommended practices to avoid this behavior would be greatly appreciated. Thank you!

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.

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

When scheduling a local notification, it can be delayed by up to 5 seconds. On iOS 26, the notification appears instantly at the scheduled time. Feedback ID: FB23218437

We are seeing a cross-app session-isolation issue involving DeviceAccess / AccessorySetupKit and Accessory Notifications. Setup: Garmin Connect owns an authorized Forerunner 745. Our app owns an Amazfit Active 3 Premium and an Amazfit Bip Max. Both Amazfit devices have working NotificationsForwarding DAExtensionSession instances. Reproduction: Keep notification forwarding working for the Amazfit devices, then forget the Garmin Forerunner 745 in iOS Settings > Bluetooth. DeviceAccess correctly removes only the Garmin device and emits DeviceLost for Garmin DeviceID C175AA77-... (com.garmin.connect.mobile). In the same millisecond, usernotificationsd invalidates two unrelated NotificationsForwarding sessions: CID 0x2D07001D, DeviceID 13D01E46-..., BundleID com.huami.watch CID 0x2D07001C, DeviceID D86C37A0-..., BundleID com.huami.watch The second session belongs to Bip Max. About four seconds later, notifications fail with: post() failed: no connection hasExtensionSession: false Bip Max remains Authorized and BTPaired, and its DADevice and notification capability remain present. Only its usernotificationsd-held NotificationsForwarding DAExtensionSession is lost. usernotificationsd also logs AccessoryNotifications.AccessoryError Code=5 while clearing the Garmin accessory record. Should DeviceLost ever invalidate NotificationsForwarding sessions with a different DeviceID and owning app? Is there a supported way to rebuild the missing session without removing and re-authorizing the retained accessory? Timestamp: 2026-08-31 14:08:46.973 local time. Full identifiers, tokens, and logs are omitted; we can provide a sysdiagnose and log archive through Feedback Assistant.

Hello Apple Developer Technical Support, We observed an unusual increase in APNs 410 Unregistered responses in our production iOS app between July 10 and July 24, 2026: Before July 10: approximately 1,500–5,000/day July 10–24: approximately 15,000–30,000/day, a 5–10x increase After July 24: the volume stabilized and did not continue to increase We found no relevant changes to our client, server, or APNs configuration during this period, and no corresponding increase in 403 ExpiredProviderToken or 400 BadDeviceToken. We also found that the last app-open dates of the affected tokens were broadly distributed from August 2025 to June 2026, with no clear concentration around a specific inactivity period. We are not using 410 Unregistered as an uninstall signal. Our main concern is understanding why the response volume increased so significantly during this specific period. Could Apple confirm: Whether there were any APNs-side changes, maintenance activities, or changes in token processing behavior between July 10 and July 24 that could explain this increase? For a device token that becomes invalid due to app uninstallation, after how many push attempts would APNs typically return a 410 Unregistered response? Is it expected to return 410 on the first push attempt, or only after multiple push attempts?

We are facing an issue with push notifications on our iOS production application and would appreciate guidance. Issue Summary Push notifications were working correctly previously but stopped working around two weeks ago. We use Firebase Cloud Messaging (FCM) for push notifications, which delivers notifications to our iOS application through APNs. The issue appears to be related to existing FCM tokens. Existing FCM Token We have an FCM token already stored in our production backend database. When we try to send a notification using this token: Our backend sometimes receives the following response: { "error": { "code": 404, "message": "NotRegistered", "status": "NOT_FOUND", "details": [ { "@type": "type.googleapis.com/google.firebase.fcm.v1.FcmError", "errorCode": "UNREGISTERED" } ] } } In some cases, the API request appears successful, but the notification is still not received on the iPhone. We also copied the exact same existing token and tested it directly using Firebase Console → Send test message. The notification was not received on the device. Newly Generated / Retrieved FCM Token We then generated/retrieved the FCM token again from the same application and tested it directly from Firebase Console. Using the newly retrieved token: The notification was successfully received on the same iPhone. This means the following behaviour is observed: Existing FCM Token ↓ Backend may return 404 UNREGISTERED OR Firebase may accept the send request ↓ Notification not received But after retrieving the token again: FCM Token Retrieved Again ↓ Firebase Console Test ↓ Notification received successfully Client-Side Configuration We have confirmed the following: APNs device token is successfully generated. FCM registration token is successfully generated. Notification permission is granted. The application is connected to the correct Firebase project. FirebaseAppDelegateProxyEnabled is set to NO. Since Firebase method swizzling is disabled, we manually assign the APNs token to Firebase Messaging. Our APNs registration code is: func application( _ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data ) { print("*** APNS Device Token: ", deviceToken) Messaging.messaging().apnsToken = deviceToken Messaging.messaging().subscribe(toTopic: "testing_new_events") { error in if let error = error { print("*** Failed to subscribe: \(error.localizedDescription)") } else { print("*** Subscribed to topic successfully") } } } Main Question About the 404 UNREGISTERED Response One part of this behaviour is particularly confusing to us. If Firebase returns: 404 UNREGISTERED NotRegistered for a particular FCM token, we would expect that token to be invalid and that the application should receive or generate a completely new FCM registration token. However, when we retrieve the FCM token again from the application, Firebase may return the same token value again. Our question is: If Firebase considers an FCM token unregistered and returns 404 UNREGISTERED when sending a notification, why can Messaging.messaging().token() or the token callback still return the same token again instead of generating a new token? For example: Token A stored in backend ↓ Backend sends notification ↓ FCM returns 404 UNREGISTERED ↓ App retrieves FCM token again ↓ Firebase returns Token A again We would like to understand whether this is expected behaviour. Specifically: Does UNREGISTERED always mean that the locally cached FCM token should immediately be replaced with a new token? If not, why can the same FCM token still be returned to the application after Firebase returns UNREGISTERED for it? Is there a delay between Firebase invalidating a registration for sending and the client generating a replacement token? Is there a recommended way to force Firebase Messaging to refresh or re-register an FCM token after receiving UNREGISTERED? Could the token be cached locally even though its server-side registration is no longer valid? Additional Questions We would also appreciate guidance on the following: Is it possible for an existing FCM token to become stale or no longer usable for notification delivery without immediately returning an UNREGISTERED error for every send attempt? Can Firebase accept a message for an existing token and return a successful response, while the notification is never delivered to the device? On iOS, could the relationship between an existing FCM token and its APNs token become invalid or stale, while the application still returns the same FCM token? Is there any APNs-side reason why an old FCM token would stop receiving notifications while a newly generated/retrieved token on the same device receives notifications successfully? What is the recommended client-side and backend-side handling after receiving a 404 UNREGISTERED response? Should we immediately remove the token from our database and wait for the application to register a new token? Our main concern is understanding why an FCM token can receive a 404 UNREGISTERED response during sending, but the application can still return the same token when we attempt to retrieve it again. Any guidance on whether this behaviour is expected, particularly regarding the interaction between FCM token registration and APNs on iOS, would be greatly appreciated.

We completed an App Store app transfer and the Notification Service Extension Filtering Entitlement (com.apple.developer.usernotifications.filtering) did not transfer with the app. App Apple ID: 6760007376 NSE Bundle ID: io.nolink.ios.nse New Team ID: M85WA8W78C Previous Team ID: V2E3A94DC9 The app, bundle IDs, and App Store presence all moved normally, but the entitlement is not available on the new team, so we cannot sign the NSE with the configuration the app previously shipped with. Our app is an encrypted messenger and this breaks incoming call handling for live users. Two questions: Is there an official process for re-associating a previously approved entitlement with the receiving team after a transfer, or does the new team always have to submit a fresh request? Could entitlements tied to a specific App ID move with the app during a transfer, the same way bundle IDs do? We have an open support case, but wanted to raise the general question here too.

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.

Hello guys, We have updated our app icon, and it is correctly reflected in our app build and assets. However, the push notification icon is still displaying the old version for some users. ✅ We have verified that: All icon assets in Assets.xcassets match the new icon. The app icon has been updated in Info.plist. The app has been resubmitted and approved on the App Store. ❌ However, some users still see the old notification icon, even after reinstalling the app. Restarting the device does not always resolve the issue. Could you provide insights into how iOS caches notification icons and how we can force a refresh for all users?

We're experiencing an issue where push notifications are not being received on certain iOS devices, and we'd like help identifying the possible causes. What we've confirmed so far: Push notifications are sent from our own provider server to APNs. APNs returns a normal response (HTTP/2 200) The device tokens are valid and up to date. Affected users have confirmed that notifications are enabled for our app in Settings. Users report no network connectivity issues. We are sending with apns-priority: 10 and apns-push-type: alert. Scope: This is occurring for multiple users, not isolated to a single device. It happens intermittently — some notifications from the same campaign reach the device, while others don't. Critically, some affected users report that they only fail to receive notifications from our app during certain specific time windows, while notifications from other apps arrive normally during the same period. This suggests the issue is app-specific and time-correlated, rather than a device-wide or network-level problem. Questions we'd like help with: Given that APNs returns 200, are there known scenarios where the notification still doesn't reach the device? (e.g., Focus / Do Not Disturb, low power mode, high-frequency throttling, stored-then-discarded due to apns-expiration) Is there a recommended way to obtain per-notification delivery status in the production environment? Are there known limits on how many notifications can be sent to the same device within a short window before APNs starts throttling or coalescing them? Our server logs currently do not retain the apns-id returned by APNs. If we provide the affected device tokens along with the approximate send timestamps, would it be possible for Apple to help investigate the delivery status of those notifications on the APNs side? Any guidance or pointers to relevant documentation would be greatly appreciated. Thank you!

Beginning July 29, 2026, we observe communication erros while sending push notifications to https://api.push.apple.com like: Error in the HTTP2 framing layer Send failure: Connection reset by peer Also we ran tcpdump which clearly indicates that TCP RESET packets are coming from various APNS IP like 17.188.x.x. Errors mostly occure during traffic peak but also outside. We also did a test from different datacenter in other country and which resulted a same issue

We're investigating an edge case around push/local notification handling on macOS when multiple instances of the same app are running simultaneously, launched via open -n /path/to/App.app. We're aware this isn't the standard/expected usage pattern for macOS apps, which are singleton by default, but we need to understand and correctly handle this case, so any clarity here would help. Setup: macOS app, AppKit, using NSApplicationDelegate and UNUserNotificationCenterDelegate. Two separate processes of the same app launched via open -n, each independently calling UNUserNotificationCenter.current().delegate = self and registerForRemoteNotifications() on launch. Questions: Device token : is the device token unique per device and app installation, or could two separately-running processes of the same installed app each be issued a different token? Our understanding from Apple's documentation is that the token identifies the app and device combination, not a specific process. Can you confirm this holds even in a multi-instance scenario? Notification tap routing : when a notification, local or remote, is tapped and both process instances have independently registered a UNUserNotificationCenterDelegate, which instance's delegate receives userNotificationCenter didReceive withCompletionHandler? Is this deterministic, for example the most recently registered instance, or the one most recently connected to usernoted? Is it arbitrary or undefined? Or does the system only allow one instance's delegate connection to be active at a time, silently disconnecting the other? Is there any documented or recommended way for an app to detect it's running as a secondary instance launched via open -n, and adjust its notification handling behavior accordingly, if relevant? We understand this falls outside the normal supported usage pattern for macOS apps, but since the behavior isn't documented for this scenario, any insight, even confirming this is undefined behavior, would be genuinely useful for us to plan around.

It's been 2+ months now since I've submitted an entitlement request for the Notification Service Filtering Entitlement (NSE). I have a mobile app that I transferred from a previous developer account due to business reorganization and the previous account had this entitlement. However, after transferring the app, I am unable to push any updates to the app on iOS because the new developer account does not have the same entitlement. Everything outside of the developer account that the app is associated to remains the same - same workflow, same audience, same app use cases, etc.. However, we still have not had any progress on receiving the entitlement even after multiple escalations and follow-ups with the Apple Developer Support team. I am curious to know if any others within the Developer Community have requested this specific entitlement before and what your experience has been with it? Any advice on how I can expedite the approval for the entitlement? Otherwise our app continues to go stale on the iOS app store.