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.