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.

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.

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