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.

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

Environment Xcode 26.5 beta iOS 26.5 beta Using AccessorySetupKit + AccessoryTransportExtension framework Three extensions: AccessoryTransportAppExtension, AccessoryTransportSecurityExtension, AccessoryDataProviderExtension Background Everything worked correctly on iOS 26.4 beta. All three extensions shared the entitlement com.apple.developer.accessory-transport-extension, and the system launched them as expected. After upgrading to iOS 26.5 beta (both Xcode and device), the app compiles and runs, the accessory pairs and connects successfully (state = authorized, BLE connected, notification forwarding = allow), but none of the extensions are launched by the system. Investigation Captured system Console logs from the device and found these errors from deviceaccessd: error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryDataProviderExtension' is missing entitlement: com.apple.developer.accessory-data-provider for com.apple.accessory-data-provider error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryTransportSecurityExtension' is missing entitlement: com.apple.developer.accessory-transport-security for com.apple.accessory-transport-security It appears that iOS 26.5 now requires per-extension-type entitlements instead of the shared one. On iOS 26.4, all three extensions used com.apple.developer.accessory-transport-extension and it worked. On iOS 26.5, deviceaccessd now expects com.apple.developer.accessory-transport-security for the security extension and com.apple.developer.accessory-data-provider for the data provider extension. The transport app extension did not report an error, so it may still accept the old entitlement. Attempted Fix Changed the entitlement keys in the .entitlements files to match what deviceaccessd expects. Xcode fails to build with: ▎ Entitlement com.apple.developer.accessory-data-provider not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. Root Cause Checked Apple Developer Portal — only one capability is available: "Accessory Transport Extension", which maps to com.apple.developer.accessory-transport-extension. There are no separate capability options for the new entitlements. The iOS 26.5 beta system requires new per-extension-type entitlements, but the provisioning system does not yet support them. This makes it impossible to build a working AccessoryTransport app on iOS 26.5 beta. Request Please either add the new entitlement capabilities (com.apple.developer.accessory-transport-security, com.apple.developer.accessory-data-provider) to the Apple Developer Portal, or restore backward compatibility with com.apple.developer.accessory-transport-extension in deviceaccessd.

Environment iOS Version: 26.4 Beta (Build 17E5170d) Xcode Version: 26.4 Beta Framework: AccessoryNotifications, AccessoryTransportExtension Description When implementing AccessoryNotifications.NotificationsForwarding.AccessoryNotificationsHandler, I'm unable to retrieve the URL for sourceIcon from AccessoryNotification. The file.url property throws AccessoryError error 0 with the message "unable to get file URL". Code Sample func add( notification: AccessoryNotification, alertingContext: AlertingContext, alertCoordinator: any AlertCoordinating ) { Task { if let sourceIcon = notification.sourceIcon { do { let url = try await sourceIcon.url // Throws AccessoryError error 0 let data = try Data(contentsOf: url) // Process icon data... } catch { print("Failed to get sourceIcon URL: (error)") // Error: The operation couldn't be completed. // (AccessoryNotifications.AccessoryError error 0.) } } } } Observed Behavior The sourceIcon property is present and its type is correctly reported as public.image: │ sourceIcon : present │ type.identifier : public.image │ type.description : image │ url : (error: The operation couldn't be completed. (AccessoryNotifications.AccessoryError error 0.)) Error details: Error: customError(message: "unable to get file URL") Type: AccessoryError Code: 0 Expected Behavior The file.url property should return a valid URL that allows reading the source icon image data, or the documentation should clarify any limitations or prerequisites for accessing this resource. Questions Is this a known limitation in the current beta? Are there additional entitlements or permissions required to access sourceIcon.url? Is there an alternative API to retrieve the actual image data for sourceIcon? Additional Context The same error occurs when accessing url in both describeNotification (debug logging) and sendAttachment methods contextIcon is typically nil for the notifications tested (e.g., WeChat messages) The notification metadata (title, body, actions, etc.) is correctly received

Hello Apple, I am a Bluetooth peripheral developer. Recently, I encountered the following issue while developing a Bluetooth smartwatch on iOS: I have a Bluetooth smartwatch that supports CTKD connections. After pairing and connecting with an iOS device, notifications from iOS can be sent to the watch normally. However, after a few days, I noticed that my watch stopped receiving any iOS notifications. Upon checking my phone's Bluetooth settings, I found that the watch's Bluetooth connection on the phone system had disconnected and did not automatically reconnect. After manually reconnecting, I observed that only the BT (classic Bluetooth) connection was established, while the BLE (Bluetooth Low Energy) connection remained disconnected. I would like to understand what could be causing this issue and how to resolve the problem of Bluetooth reconnection.

After a prolonged BLE connection, we have noticed that ANCS frequently pushes a large number of "remove" messages (event ID 0x02), after which the device no longer receives any notifications. Is this behavior a result of system design, or could it be a potential bug? I would appreciate any insights or experiences that others can share.