Integrate AccessorySetupKit for pairing

[Supereg]

Name of the PR

♻️ Current situation & Problem

Link any open issues or pull requests (PRs) related to this PR. Please ensure that all non-trivial PRs are first tracked and discussed in an existing GitHub issue or discussion.

⚙️ Release Notes

Add a bullet point list summary of the feature and possible migration guides if this is a breaking change so this section can be added to the release notes.
Include code snippets that provide examples of the feature implemented or links to the documentation if it appends or changes the public interface.

📚 Documentation

Please ensure that you properly document any additions in conformance to Spezi Documentation Guide.
You can use this section to describe your solution, but we encourage contributors to document your reasoning and changes using in-line documentation.

✅ Testing

Please ensure that the PR meets the testing requirements set by CodeCov and that new functionality is appropriately tested.
This section describes important information about the tests and why some elements might not be testable.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[PSchmiedmayer]

@Supereg I have made some further improvements on #120 to improve test stability & the overall deployment setup.

Wanted to follow up on the current state of the Accessory Setup PRs; most of them seem close to ready. Might not be a high priority but could be cool to merge it at some point in the future to close the PRs and tag more stable releases around these features.

[Supereg]

@Supereg I have made some further improvements on #120 to improve test stability & the overall deployment setup.

Wanted to follow up on the current state of the Accessory Setup PRs; most of them seem close to ready. Might not be a high priority but could be cool to merge it at some point in the future to close the PRs and tag more stable releases around these features.

Thank you for merging the deployment improvements. The PR is roughly ready. However, we haven't touched migration yet which is important if you are upgrading from previous installations or previous iOS installations. As soon as you opt into AccessorySetupKit you can no longer access previous Bluetooth devices and you need to migrate. The migration step is a bit finicky (according to documentation) where you must make sure that this happens before the CBBluetoothCentral is initialized the first time. At the same time, this presents a picker view from AccessorySetupKit which should not interfere with with the applications content. We haven't defined this step yet, therefore, some work might still be required here 👍

[PSchmiedmayer]

Sounds fair; thank you for the context!

Wondering if that migration would generally be part of SpeziBluetooth? Could we aim to generalize this or would this be something that should be done in reach repo?

[Supereg]

Sounds fair; thank you for the context!

Wondering if that migration would generally be part of SpeziBluetooth? Could we aim to generalize this or would this be something that should be done in reach repo?

Similar to the existing interaction, some implementation details (e.g. deriving the migration items from SpeziBluetooth descriptor types) can and should be part of SpeziBluetooth. But most interactions are probably part of SpeziDevices (as it is now). At least, if you use the SpeziDevices-based persistence Module everything should happen nearly transparently.

[PSchmiedmayer]

Sounds fair, you are right, SpeziDevices should be the final abstraction layer that ideally makes it easy to add AccessorySetupKit support without any additional effort in an app. What would be great 🚀