iāve written a basic BLE beacon scanner for iOS, with parsers for ruuvi tag raw and Eddystone formats. Since there seems to be nothing else with ruuvi support on iOS right now, iāve published it - maybe somebody will find it useful.
More information here: http://corebeacons.fluthaus.com.
Itās nothing fancy, just a byproduct of playing around with my ruuvi tags and dipping my toes a bit into Bluetooth LE, so please donāt expect too much. And naturally, itās limited in some aspects by these many frustrating shortcomings of the weird iOS CoreBluetooth APIā¦ iāll try to contain myself and not rant at length about it
Could you confirm the feature to differentiate sensors from each other works ok, except the identifiers are not reproducible?
As long as the app + installation + device remain same, will also the UUIDs remain the same? What about when the app gets updated? Will it break the custom names?
No reproducible identifiers: CoreBluetooth denies access to the mac address of a BLE device; instead it assigns an UUID, which is different for every application, installation and iOS device. This makes it impossible to identify a beacon across applications, installations or iOS devices.
From what iāve seen, the CoreBluetooth assigned UUIDs seem to be persistent:
over iOS device reboots
over version changes of the application (CFBundleVersion as well as CFBundleShortVersionString)
over changes in the BLE peripherals characteristic: advertised service types, manufacturer data
over reboots of a peripheral
The UUIDs change
when the application identifier (CFBundleIdentifier) changes[Edit: maybe I was wrong about this, will have to investigate]
over macOS reboots
I havenāt had a chance to test (yet):
iOS updates
exchange of iOS devices for a given installation (like when transferring to a different device over iCloud or iTunes backup/restore)
All based on the limited selection of iOS devices and hence iOS releases available to me (canāt test in iOS Simulator, since CoreBluetooth there is just a stub)
So, for me, it seems stable enough for labeling beacons in a developer tool - in the end, you hopefully donāt lose that much if it breaks -, but with no detailed documentation*, i wouldnāt build my business model on it.
*) CBPeer.h only states that itās a āunique, persistentā identifier, and the API documentation is even more vague. And that itās actually persistent i think can be doubted, see macOS reboots above
Ok, this is not so good Because, for now, we would like to continue shipping Tags with a factory preloaded data format 3 firmware which has no identifier embedded on the data packet. And at the same time would like support also multiple Tags on iOS.
Need to think about this. Maybe it would be āokā to tell users to upgrade their firmwares if they would like to overcome this feature.
sorry, that was unclear: I literally meant āmacOSā, like, in āApples desktop osā. I 've observed UUIDs change after reboot there, while playing with a macOS version of Core Beacons (which got mostly abandoned over the even worse discovery performance of CoreBluetooth on macOS; discovery often takes minutes).
On iOS, in contrast, iāve not yet seen CoreBluetooth assigned UUIDs - the value of the CBPeer āidentifierā property, to be precise - change after an iOS device reboot. Of course, this is no guarantee - as mentioned, the documentation is vague, and incorrect in the case of macOS - so we canāt know for sure which behaviour to expect.
Regarding the firmware: Thatās fine for Core Beacons. On the long term, to my understanding, apps on iOS would benefit from features like connectability - which seemingly makes a big difference on how CoreBluetooth lets an app communicate with a peripheral, especially while being in the background. And iirc, Apple suggests some other details, like certain advertisement timing intervals, for BLE devices to be reliably detected by āApple productsā.