Integrate AccessorySetupKit for Pairing

[bauer-andreas]

Integrate AccessorySetupKit for Pairing

⚙️ Release Notes

• Integrate AccessorySetupKit for Pairing

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.

[bauer-andreas]

@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?

[bauer-andreas]

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 🚀

[PSchmiedmayer]

@Supereg We have resolved the UI testing issues in #143; would make sense to merge main back in here to get this PR eventually merged 🚀