State restoration with AccessorySetupKit for a poll-based accessory

Question

Created 1h

Replies 3

Boosts 0

Participants 2

This post is from the WWDC26 AccessorySetupKit Q&A.

Hi! I'm using AccessorySetupKit with CoreBluetooth state restoration. My understanding is that using AccessorySetupKit is a now pre-requisite to enabling the state restoration/preservation apis, so I went that route — and pairing, handoff, and restoration on search discovery or connection completion seem to be working

Where I'm stuck: my accessory is poll-based. I read it by writing a request and reading the response. Then I send a new request. the BLE accessory never pushes data on its own. Since restoration only seems to wake my app on an inbound BLE event, if the app gets terminated mid-session while the connection's still healthy, nothing wakes the app and polling just quietly stops.

Is there a recommended way to handle this for a request/response device? Thanks!

Answer 1

Engineer OP

Apple

1h

Hello.

Bluetooth state restoration is driven by accessory communication, so if your app is no longer running of if its suspended, an accessory can send a Bluetooth communication over GATT,so you will need to switch your mode to a notification/indication model when the accessory can send you a notification over the Bluetooth link to restore your app.

Answer 2

mountaincoder OP

1h

What if your accessory does not support the notification/indication model?

Answer 3

Engineer OP

Apple

46m

CoreBluetooth tech notes can be found here

In order to get runtime when app is suspended or get your app restored if killed is to make sure accessory is sending information over Bluetooth. This can either be a notification from the accessory over the connection, or you can scan for it and advertise a different payload indicating it has data, which will wake your app as the new payload is different and will get through the duplicate filter.