CBPeer.identifier changes after OS update and device reboot on iOS 27 (non-bonded BLE peripheral)

Is it intended behavior in iOS 27 that CBPeer.identifier for a non-bonded BLE peripheral changes after an OS update or device reboot?

CBPeer.identifier is not intended to be a truly fixed identifier and it will change under a variety of conditions. Our original design, the primary trigger was accessory level changes (like changing its address) but over time it's only become less stable, primarily because of privacy/tracking concerns. Note that AccessorySetupKit (ASK) has facilitated us making it "less stable", since ASK provides a much stabler accessory reference and is our recommend discovery/management API.

If this is by design, is there any documentation (release notes, technical documents, API reference, etc.) that describes this change?

It's by design in the sense that the framework is really only attempting to keep it stable in the short term so that an app that's interacting with the same accessory in an "active" way can use the identifier to maintain it's connection with that accessory.

Under what conditions can the CBPeer.identifier of a non-bonded BLE peripheral change? (e.g., OS update, device reboot, resetting Bluetooth settings, reinstalling the app, after a certain period of time, etc.)

We've never documented this.

If we need to keep identifying the same non-bonded BLE peripheral across reboots and OS updates, what implementation approach do you recommend?

You really only have two choices:

1. Move to AccessorySetupKit.

2. Embed enough information in the accessory itself that you're able to identify after you retrieve it via scanning.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin,

Thank you for the detailed and clear answer. It confirms that our current approach, which persists CBPeer.identifier and uses it to recognize the same peripheral over the long term, is not supported. We will move away from it.

Following your recommendation, we are evaluating a migration to AccessorySetupKit. Before we commit to it, I have a few follow-up questions:

1. Stability of the ASK identifierIs

ASAccessory.bluetoothIdentifier expected to stay the same across device reboots and iOS updates for as long as the accessory remains authorized? Or are there known conditions under which it can change, such as resetting Bluetooth settings or reinstalling the app?

2. Identical accessories in the picker

Our accessories all advertise the same service UUID and similar names. Several of them may be within range at the same time. Is there a recommended way to make sure the user picks the correct one? For example, can we limit discovery to nearby accessories, or customize the display items based on advertisement data?

3. Migrating existing users

For users who already registered their accessory using the old identifier-based approach, is ASMigrationDisplayItem the intended way to move them over? Does it work even if the stored CBPeer.identifier has already changed after the iOS 27 update?

Thank you again for your help.

Best regards, ks-mwlk

1. Stability of the ASK identifierIs

ASAccessory.bluetoothIdentifier expected to stay the same across device reboots and iOS updates for as long as the accessory remains authorized?

Yes.

Or are there known conditions under which it can change, such as resetting Bluetooth settings

Turning bluetooth On/Off won't, but I believe "Reset Network Settings" or forgetting the accessory will.

or reinstalling the app?

I don't think this will but I'm not certain.

1. Identical accessories in the picker

Our accessories all advertise the same service UUID and similar names. Several of them may be within range at the same time. Is there a recommended way to make sure the user picks the correct one? For example, can we limit discovery to nearby accessories, or customize the display items based on advertisement data?

Basically, "yes, you can do all that". The article "Discovering and configuring accessories" covers all this, but make sure you read to the end, as that's where these details are covered.

1. Migrating existing users

For users who already registered their accessory using the old identifier-based approach, is ASMigrationDisplayItem the intended way to move them over?

Yes.

Does it work even if the stored CBPeer.identifier has already changed after the iOS 27 update?

No, probably not. However, there's no real downside in trying. Also, note that migration doesn't require you to have access to the accessory (for example, you can migrate an accessory that's turned off), so you won't really "know" whether or not it's worked when you migrate the accessory.

__
Kevin Elliott
DTS Engineering, CoreOS/Hardware