Feat/device setup

[marcosinigaglia]

This pull request introduces a broad renaming and refactoring of the "companion" device setup feature across both Android and iOS platforms, standardizing terminology to "device setup" and improving code robustness and clarity. It also updates the example app to use the new APIs, enhances Bluetooth scanning logic, and adds iOS 18 AccessorySetupKit support for device setup. Below are the most important changes grouped by theme:

API and Naming Standardization:

• Renamed all "companion" methods, events, and variables to "device setup" equivalents in both Android (BleManager.java, CompanionScanner.java) and iOS (BleManager.h, BleManager.mm, SwiftBleManager.swift), including exported methods like companionScan → deviceSetupScan, supportsCompanion → supportsDeviceSetup, and related event emitters. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

iOS Device Setup Support:

• Added initial support for iOS 18's AccessorySetupKit, including a method to build a payload from an ASAccessory, and session management for accessory setup flows in SwiftBleManager.swift. [1] [2]

Android Robustness Improvements:

• Improved null-safety and error handling in CompanionScanner.java by using Objects.requireNonNull and checking for nulls before accessing values. [1] [2] [3]

Example App Updates:

• Updated the example app to use the new "device setup" APIs, increased scan duration, set a specific service UUID, and improved Bluetooth initialization logic to ensure the BLE manager is started before scanning. Also cleaned up UI and button logic for device setup and Bluetooth enabling. [1] [2] [3] [4] [5] [6] [7] [8] [9]

iOS Permissions:

• Added required iOS AccessorySetupKit and Bluetooth permissions to the example app's app.config.js for iOS 18 compatibility.

[lucaswitch]

Hey whats left for this PR be approved?

[marcosinigaglia]

Hey whats left for this PR be approved?

Hi, It's not complete and I don't have time now. Also I'm not convinced it's the right solution, the mechanisms are different, and it might be better to keep them separate by platform.

[lucaswitch]

I had an pr that implement that Em qui., 28 de mai. de 2026 às 05:26, Marco Sinigaglia < ***@***.***> escreveu:

…

*marcosinigaglia* left a comment (innoveit/react-native-ble-manager#1409) <#1409 (comment)> Hey whats left for this PR be approved? Hi, It's not complete and I don't have time now. Also I'm not convinced it's the right solution, the mechanisms are different, and it might be better to keep them separate by platform. — Reply to this email directly, view it on GitHub <#1409?email_source=notifications&email_token=AG5NZ474BNGKV6GDUNEWRV3447Z35A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJWGIYDSNZWGQ4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4562097648>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG5NZ452R3526MDQMN4X2HT447Z35AVCNFSM6AAAAACZPXJBX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNRSGA4TONRUHA> . You are receiving this because you commented.Message ID: ***@***.***>

[lucaswitch]

Hey whats left for this PR be approved?

Hi, It's not complete and I don't have time now. Also I'm not convinced it's the right solution, the mechanisms are different, and it might be better to keep them separate by platform.

I can help you with that, we just need to agree on unified api for both platforms.
Cause having two separated apis will cause a initial friction on using it.