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.