AccessorySetupKit + CBCentralManager migration & scanning regression after accessory picker authorization

Question

Frank_Test OP

Created 18h

Replies 1

Boosts 0

Participants 2

Hello everyone:

Description

Environment

iOS: 26.5
Xcode: 26.3
App version: 1.0 / 2.0

Scenario background

App communicates with unpaired Bluetooth peripherals.

App v1.0: Use only CBCentralManager for scanning and connecting peripherals(D2, D3…). No AccessorySetupKit involved.
App v2.0: Hybrid approach: ASAccessorySession + CBCentralManager.

CBCentralManager is initialized after ASAccessorySession becomes active.

Info.plist configuration

<key>NSAccessorySetupKitSupports</key>
<array>
    <string>Bluetooth</string>
</array>
<key>NSAccessorySetupBluetoothServices</key>
<array>
    <string>xxxx</string>
</array>
<key>NSAccessorySetupBluetoothNames</key>
<array>
    <string>MyDevice</string>
</array>

Observed test behavior For users upgrading from v1.0 to v2.0:

ASAccessorySession.accessories returns empty.
Old CBCentralManager instance(C1) works fine: can scan and connect peripherals D1, D2, D3.
Calling showPicker() while C1 is alive throws error:

Error Domain=ASErrorDomain Code=550

Destroy C1 before invoking showPicker(). After user authorizes new accessory D1 via picker, create a brand‑new CBCentralManager instance(C2).
Regression: C2 can only scan & communicate with authorized D1. Peripherals D2, D3 can no longer be discovered.

Questions

In v1.0 we stored CBPeripheral.identifier for unpaired devices D2, D3. How to implement seamless migration after upgrading to v2.0?
After user authorizes D1 in v2.0, is there a callback trigger when D2 / D3 come into proximity? Can we auto‑launch showPicker() on that trigger?
AccessorySetupKit workflow feels restrictive. Is multi‑device one‑tap authorization planned for peripherals like D2, D3 which may not be nearby at authorization time?

Answer 1

DTS Engineer OP

Apple

2h

In v1.0, we stored CBPeripheral.identifier for unpaired devices D2 and D3. How to implement seamless migration after upgrading to v2.0?

Have you tried using ASMigrationDisplayItem to migrate the accessory into AccessorySetupKit, as described in "Use the picker when migrating to AccessorySetupKit"? I believe the way this is supposed to work is that you give the system your existing peripheral identifier(s), which the system then allows the user to import. The accessory doesn't need to be visible/active for this to work, as the system relies on the data it retrieved in the past.

After the user authorizes D1 in v2.0, is there a callback trigger when D2 or D3 come into proximity? Can we auto‑launch showPicker() on that trigger?

If you migrated the accessories, then that shouldn't be necessary, as you can discover them through CoreBluetooth. For "new" accessories, the expectation is that the user would initiate pairing through your app, instead of your app detecting them.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware