On a single device, a production-entitlement build of our app calls -[UIApplication registerForRemoteNotifications] and neither delegate callback is ever invoked. Not application:didRegisterForRemoteNotificationsWithDeviceToken:, and not application:didFailToRegisterForRemoteNotificationsWithError:. We wait 10 seconds and get nothing, on every launch, over more than 24 hours. UNAuthorizationStatus is .authorized, verified programmatically at the moment of the call rather than just in Settings, and the installed binary carries aps-environment = production, read off the device. The identical source signed with aps-environment = development receives a token in under one second on that same handset. We have isolated it to one cell of a four-way matrix. Production entitlement on this device: no token, no error, reproducing on both the App Store and TestFlight builds. Development entitlement on this device: token in under one second. Production entitlement on other devices: works, and other users register daily. Production APNs for other apps on this device: works, other App Store apps receive push normally. Already ruled out: notification authorization; the entitlement; delegate wiring (UIApplicationDelegateAdaptor is attached, and that same delegate receives the token when the app is development-signed); delete and reinstall from both the App Store and TestFlight; Reset Network Settings; reboot; airplane-mode cycle; an alternate network. Device context: iPhone 12 Pro (iPhone13,3) on iOS 26.6.1 (23G83). It is an AppleCare replacement unit, restored from a backup of the previous handset. Our working theory is stale per-app push registration state carried across in that restore, since reinstalling does not clear it, which suggests whatever is stuck does not live in the app container. Filed as FB24525199 with a sysdiagnose captured while the APNs logging profile was installed. Two questions. First, is there any way to force a device to discard and re-provision its per-app APNs registration state, short of erasing and setting up as new? Second, is the absence of both callbacks a known state? Every reference I can find treats didFailToRegisterForRemoteNotificationsWithError as the guaranteed path when registration cannot complete, so silence from both leaves an app with no signal to act on and no way to tell the user what is wrong.

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

Title: Multi-accessory DeviceAccess bugs: wrong PeripheralID in Transport wake-up; cross-device NotificationsForwarding session invalidation Topic: App & System Services → Core OS Tags: Core Bluetooth, AccessorySetupKit, Notifications Body: Context: our app uses AccessorySetupKit and a DeviceAccess-based accessory Transport + DataProvider extension pair (one shared extension bundle serves all accessories). Everything works with a single bound accessory, but with two or more ASK accessories on the same app we consistently hit two independent system-level failures. Both fail BEFORE any app callback runs (no DataProvider addNotification, no Transport messageReceived), so this is not app-side parsing or business logic. Tested on iPhone 11 Pro, current iOS 26 release; full logarchives available and can be attached to a Feedback Assistant case. Problem 1 — Transport wake-up requests use the wrong PeripheralID (uplink: watch reply → iPhone) Reproducible timeline from bluetoothd/deviceaccessd logs: Device A's GATT indication reaches bluetoothd; CoreBluetooth routes it to device A's CoreBluetooth session (its Transport PID). ~8 ms later, the DAExtensionRuntimeAssertion that bluetoothd sends to deviceaccessd carries device B's PeripheralID instead of device A's. deviceaccessd then resumes/updates device B's Transport. Device A's Transport stays suspended and never receives the data; the reply is lost. Two outcomes depending on whether the wrongly-used PeripheralID still resolves: Belongs to another still-bound accessory: the assertion "succeeds" and the wrong Transport instance is resumed — no error at all. Belongs to an already-removed accessory: DAErrorDomain 350002 "device not found". So the absence of error 350002 does not mean the mapping is correct. Re-authorizing the affected accessory via ASK does NOT repair the mapping: after re-ASK, notification delivery works again, but once the new Transport suspends, subsequent wake-ups still carry the other accessory's PeripheralID. Problem 2 — NotificationsForwarding DAExtensionSession lifecycle is not isolated per DeviceID (downlink: iPhone notification → watch) Expected: usernotificationsd holds one NotificationsForwarding DAExtensionSession per authorized accessory with notification forwarding enabled, strictly isolated by DeviceID. Observed instead: A session is "activated and stored" and then immediately invalidated by usernotificationsd itself, with no user action (four-accessory setup, three forwarding-capable). Any accessory's DeviceLost invalidates OTHER accessories' sessions. Logs show the event DeviceID differs from the invalidated session's DeviceID. This also happens when the removed accessory does not support notification forwarding at all (so there was no session of its own to clean up). After such mass invalidation, usernotificationsd may rebuild only some sessions or none — even when BLE, Transport, and DataProvider capability fully recover (e.g. after toggling Bluetooth). Notifications then stop at "post() failed: no connection (hasExtensionSession: false)". A new accessory's ASK DeviceFound triggers a rescan that rebuilds missing sessions for the older devices (consistent across our samples, but we don't know whether this is a stable contract). What we ruled out on our side: ASAccessorySession.removeAccessory is called with the correct target; nothing in the app touches other accessories' sessions or permissions. The failures happen inside system daemons before app callbacks; single-accessory flows work fine with identical code. Multiple DataProvider DAExtension records sharing one host PID behaved normally — expected ExtensionKit hosting, not the issue. Questions: Is the PeripheralID substitution in the bluetoothd → deviceaccessd DAExtensionRuntimeAssertion a known issue when one transport extension bundle serves multiple accessories? Any supported workaround? Should usernotificationsd session maintenance be strictly isolated by DeviceID? Is there a supported way to force-rebuild all NotificationsForwarding DAExtensionSessions without unbinding accessories? Is the DeviceFound-triggered full session rescan/rebuild a contract we may rely on? Happy to provide logarchives and detailed timelines via Feedback Assistant. Thanks!

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.

My app uses a notification service extension and a notification content extension, both of which are considerably complex and result in a few different dozen combinations of notification with various layouts and content. Regression testing of all the multitude of combinations of notifications is time consuming. Is there any tools available that can utilized to create a test harness? I was thinking something like the test harness sends a series of pushes and each resulting notification gets checked. Is XCUITest capable of verifying the content/layout of notifications? If so how could XCUITest be incorporated with a test harness that is driving things and sending the pushes etc.

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.

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?

Summary: After converting our Apple Developer account from Individual → Organization, our app stopped receiving APNs device tokens. application(:didRegisterForRemoteNotificationsWithDeviceToken:) is never called, and application(:didFailToRegisterForRemoteNotificationsWithError:) is also never called — no token, no error. This affects all new device‑token registrations app‑wide; device tokens issued before the conversion still work and continue to deliver pushes. Environment Membership status: Active Device: iPhone 15 Pro, iOS [26.6] Reproduced on both development (sandbox) builds installed via Xcode/CLI and TestFlight builds. What works Existing device tokens (created before ~Aug 1) still deliver pushes normally (server reports delivered 1/1 via our .p8 token‑based auth). So the send path and APNs auth key are fine. UNUserNotificationCenter authorization succeeds — authorizationStatus == .authorized. UIApplication.shared.isRegisteredForRemoteNotifications == true. What doesn't work We call UIApplication.shared.registerForRemoteNotifications() on the main thread after authorization is granted, but neither delegate callback ever fires — no token, no error — on any new install/launch. Timeline / trigger Everything worked before the Individual→Organization conversion. Since the conversion, no new APNs device token has been issued for the app at all. Server‑side we can confirm the most recent device token was created 2026‑08‑01, and none since, despite many fresh installs/launches across multiple users. Pre‑conversion tokens still function. What we've already tried / ruled out App ID has Push Notifications capability enabled; regenerated provisioning profiles. Generated a new APNs Auth Key (.p8) (sends already work, so this was expected not to matter). Fixed the Xcode signing team (it briefly showed "Unknown Name (TEAMID)" right after conversion; resolved by signing into the correct org account — Team now resolves correctly). Device reboot, network settings reset, app delete/reinstall, latest iOS. Confirmed delegate is wired (@UIApplicationDelegateAdaptor) — the same code issued tokens fine before the conversion. Thanks in advance!

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!

What I found during the development: The Apple phone has registered the device token and it is within the validity period, but it cannot receive the apns message. However, only after I re-registered the device token with this token could this iPhone receive apns push notifications normally... What's going on here? How can it be optimized?

Beginning July 29, 2026, we noticed a higher number of error responses from api.sandbox.push.apple.com: http2: server sent GOAWAY and closed the connection; LastStreamID=2147483647; ErrCode=PROTOCOL_ERROR; debug="Stream 3 does not exist for inbound frame DATA, endOfStream = true" The errors: Occur across multiple independent applications and regions. Are concentrated on the APNs sandbox endpoint. Did not coincide with a deployment or configuration change in our service. Were not accompanied by other typical failures such as 400 BadDeviceToken. Also increased on the APNs production endpoint, though the large majority remain concentrated on the sandbox endpoint. Could Apple confirm whether APNs recently changed how notification requests are validated or rejected, particularly in the sandbox environment? We can provide exact UTC timestamps, source regions, request metadata, and logs privately if needed.

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.

Updated with FB24122131. Here's the ready-to-paste forum post: Title: registerForRemoteNotifications() never completes (no success, no error callback) since July 3 — App Store Connect metrics confirm same cutoff Body: Posting in case anyone else has hit this — happy to compare notes, and I've also filed FB24122131 with Apple directly. Since ~July 3, 2026, our app (MyRoost, iOS) has been completely unable to register for remote notifications. registerForRemoteNotifications() is called at launch, but neither didRegisterForRemoteNotificationsWithDeviceToken: nor didFailToRegisterForRemoteNotificationsWithError: ever fires. No token, no error — just silence, indefinitely. This isn't a new-integration bug — the same code worked fine through July 2. What's interesting is that App Store Connect's own "Push Notifications → Overview" dashboard for our app independently shows notifications received by APNs dropping from ~20/day to flat zero starting exactly July 3, matching our own logs precisely. We've ruled out essentially everything on our side: Push Notifications capability + entitlements (independently verified present in the actual signed binary, not just source, via a CI step that dumps the compiled .ipa's Info.plist and codesign entitlements) Firebase/APNs Authentication Key configuration OS-level notification permission (confirmed granted) MDM/configuration profiles (none), Screen Time restrictions (none) Wi-Fi vs. cellular (identical failure on both) Full device reboot, clean reinstall, account logout/login Reproduced identically on two separate physical devices (iPhone 17 Pro, iOS 26.5.2; iPad A16, iPadOS 26.5.2) Added native diagnostic logging to capture the raw error from didFailToRegisterForRemoteNotificationsWithError: directly — confirms the native callback itself never fires, not just that we're failing to observe it Filed an Apple Developer Support case (102936910825) on July 8 — after investigation, closed 2026-07-30 as "outside scope" and redirected here / to Feedback Assistant. Has anyone else seen a total, silent APNs registration failure like this, starting around the same early-July timeframe? Any workaround, or confirmation this is a known platform-side issue, would be hugely appreciated.

Across two completely separate App IDs under the same Apple Developer Team, calling registerForRemoteNotifications() (via a standard push-notification plugin wrapping this exact API) resolves successfully — but afterward neither application(:didRegisterForRemoteNotificationsWithDeviceToken:) nor application(:didFailToRegisterForRemoteNotificationsWithError:) is ever called. No token, no error. Registration just stalls permanently. Environment Xcode 26.4.1 Distribution: TestFlight (App Store distribution profile → production APNs environment) iOS on all test devices: current release The key finding This isn't specific to one app. I reproduced the identical failure on: Our primary app's App ID, which has existed for a while and had Push Notifications enabled after initial creation. A brand-new, throwaway App ID created from scratch specifically to test this, with Push Notifications capability checked at creation time (no toggling after the fact, no history at all). Both show the exact same symptom: register() resolves, then silence — no callback of either kind, ever. Since this reproduces identically on an App ID with zero prior history, it rules out anything specific to one app's configuration or App Store Connect record, and points at something at the Team level with APNs backend authorization. What I've ruled out Entitlements/provisioning are correct and matching, verified via direct inspection of the signed binary: codesign -d --entitlements :- MyApp.app and the provisioning profile's own entitlements: security cms -D -i MyApp.app/embedded.mobileprovision | plutil -extract Entitlements xml1 -o - - Both show identical, correct values — aps-environment: production, correct application-identifier, correct team-identifier. Reproduced identically across: 2 separate App IDs (one long-standing, one brand new) 2 different physical iPhones 2 different WiFi networks 2 different accounts/user sessions within the app Already tried with no change in behavior: Enabling Push Notifications after initial App ID creation, vs. checking it at creation time on the fresh App ID Toggling the capability off/on and regenerating the provisioning profile Generating multiple fresh App Store distribution profiles Confirmed the Distribution certificate referenced is correct and valid Client code confirmed correct via instrumented logging at every step (permission check → permission request → listener attachment → register() call). Every step up to and including register() resolving completes exactly as expected. The stall is strictly after that point, entirely on the OS/APNs side. What I'm trying to determine Given this reproduces on a completely fresh App ID with no history, I believe this points at something about how APNs backend authorization is provisioned for this Developer Team as a whole, rather than any individual App ID's configuration. Has anyone seen this exact symptom — registration call succeeding but zero callback of either kind — and found a resolution that wasn't visible from anything in the Developer Portal or Xcode? Filed as Apple Developer Support case 20000117948923 — happy to share any additional diagnostics.

We are investigating a notification-reply issue with a BLE accessory on iOS 27 Beta 4, built with Xcode 26.5. Our app uses an Accessory Transport App Extension and an Accessory Data Provider Extension for notification forwarding and text replies. Expected behavior A text reply entered on the accessory should be delivered to the transport extension, forwarded to the data provider extension, and then submitted through the system notification response API. Observed behavior A messaging notification with a text-input Reply action is forwarded successfully to the accessory. If the user replies shortly after the notification arrives, the full path succeeds: the BLE reply payload is received by the transport extension, forwarded to the data provider extension, parsed, and the system notification response API succeeds. If the user waits about 1-2 minutes before replying, the reply fails. The original notification was forwarded successfully and BLE was ready. We see the accessory acknowledgement for notification delivery. Log evidence The successful path contains BLE receive, transport reassembly, a parsed Reply action with user text, and a successful notification response API call. In the delayed-reply case, after the background window expires the host app is reported as running-suspended. When the accessory reply is attempted, there is no new invocation of either extension and no incoming BLE reply payload in those extensions. Therefore no notification response API call is made. This does not appear to depend on screen state. The relevant difference is whether the accessory reply occurs before or after the background execution window ends. Question After an accessory notification has already been delivered, what is the supported mechanism for a delayed accessory text reply to wake or re-invoke the Accessory Transport App Extension and route the reply to the Accessory Data Provider Extension? Is this expected lifecycle behavior for these extensions on iOS 27 Beta 4, or is there an entitlement, configuration, or API requirement needed to support delayed replies? We can provide a sysdiagnose and a minimal reproduction timeline privately if needed.We are investigating a notification-reply issue with a BLE accessory on iOS 27 Beta 4, built with Xcode 26.5. Our app uses an Accessory Transport App Extension and an Accessory Data Provider Extension for notification forwarding and text replies. Expected behavior A text reply entered on the accessory should be delivered to the transport extension, forwarded to the data provider extension, and then submitted through the system notification response API. Observed behavior A messaging notification with a text-input Reply action is forwarded successfully to the accessory. If the user replies shortly after the notification arrives, the full path succeeds: the BLE reply payload is received by the transport extension, forwarded to the data provider extension, parsed, and the system notification response API succeeds. If the user waits about 1-2 minutes before replying, the reply fails. The original notification was forwarded successfully and BLE was ready. We see the accessory acknowledgement for notification delivery. Log evidence The successful path contains BLE receive, transport reassembly, a parsed Reply action with user text, and a successful notification response API call. In the delayed-reply case, after the background window expires the host app is reported as running-suspended. When the accessory reply is attempted, there is no new invocation of either extension and no incoming BLE reply payload in those extensions. Therefore no notification response API call is made. This does not appear to depend on screen state. The relevant difference is whether the accessory reply occurs before or after the background execution window ends. Question After an accessory notification has already been delivered, what is the supported mechanism for a delayed accessory text reply to wake or re-invoke the Accessory Transport App Extension and route the reply to the Accessory Data Provider Extension? Is this expected lifecycle behavior for these extensions on iOS 27 Beta 4, or is there an entitlement, configuration, or API requirement needed to support delayed replies? We can provide a sysdiagnose and a minimal reproduction timeline privately if needed.

I’m seeing what appears to be a regression in custom local-notification sounds on macOS 26.6. According to the UNNotificationSound documentation, a custom sound can be stored in the main application bundle and supplied using UNNotificationSound(named:). Environment: macOS 26.6 (25G72) Xcode 26.6 (17F113) Swift 6.3.3 Apple Silicon Sandboxed native macOS application Notification authorization granted Sounds enabled for the application in System Settings import AppKit import UserNotifications let center = UNUserNotificationCenter.current() let soundFilename = "notification_probe.aiff" guard Bundle.main.url( forResource: soundFilename, withExtension: nil ) != nil else { fatalError("Sound is missing from the application bundle") } let content = UNMutableNotificationContent() content.title = "Custom sound test" content.body = "This should play the bundled custom sound." content.sound = UNNotificationSound( named: UNNotificationSoundName(rawValue: soundFilename) ) // Ensure the application is inactive so macOS presents the notification. NSApp.hide(nil) try await Task.sleep(for: .milliseconds(250)) try await center.add( UNNotificationRequest( identifier: "custom_sound_test", content: content, trigger: nil ) ) The sound is correctly copied to: MyApp.app/Contents/Resources/notification_probe.aiff I tested two separate files: CAF and AIFF both files are shorter than 30 seconds and comply with the documented custom-sound requirements. Actual result: The notification is delivered and displayed correctly. macOS plays the default notification sound. The custom sound is not played. The unified log shows Notification Center receiving the correct custom filename, but ToneLibrary then rejects it: [com.apple.unc:sound] Playing notification sound { nam: notification_probe.aiff } for com.example.MyApp [com.apple.ToneLibrary:ToneManagement] Tone with identifier 'notification_probe.aiff' is neither in the collections for system or iTunes tones. Performed basic check for validity of tone with identifier 'notification_probe.aiff': NO. -toneWithIdentifierIsValid:(notification_probe.aiff): Returning NO. Immediately afterwards, SystemSoundServer plays the standard macOS notification sound. Immediately afterwards, SystemSoundServer plays the standard macOS notification sound At present, the only working solution is to submit a silent notification and play the sound independently through AudioToolbox, which loses the normal coupling between notification presentation and sound playback. Is this a bug or what ?