Inconsistency Between Mac and iOS With Core Bluetooth

Question

ChrisMarshallNY OP

Created Jul ’20

Replies 2

Boosts 0

Views 1k

Participants 2

META: I also asked this over on StackOverflow, but hardly anyone has even looked at the question.

I have discovered that Core Bluetooth Peripheral Discovery seems to return different results for Mac, and iOS.

iOS seems to give me a lot more info, in the discovery callback, while the Mac seems extremely sparse.

I'm wondering if anyone could shed light on why, exactly, this is.

The test project I created is about as simple as you can get.

I have a pretty much default "Hello World" SwiftUI project, with targets for MacOS and iOS, using a shared ContentView that also instantiates a VERY simple CBCentralManagerDelegate object, and prints discovery info to the console.

I will simply paste the contents of the README, below. It should explain the issue. The two console dumps were made from my Mac and my iPhone, about six inches apart, and about thirty seconds apart.

BTW: You need to run the iOS target on a device. The simulator won't work.

STRANGE CORE BLUETOOTH ISSUE

This project contains about the simplest comparison I can make for testing this.

This is the GitHub repo for this project

THE ISSUE

When a MacOS app gets the centralManager(_ central: CBCentralManager, didDiscover: CBPeripheral, advertisementData: [String : Any], rssi: NSNumber) callback, it delivers different data on the Mac, than on iOS.

The code is EXACTLY the same between them. I use a simple shared SwiftUI view to instantiate a dirt-simple CentralManager, and display discovered devices.

On iOS, I get the names of the devices.

On the Mac, I fail to get most of the names.

iOS console log:

Code Block Discovered "Soulcatcher"
Discovered "Croaker"
Discovered "One-Eye"
Discovered "[TV]Living Room TV"
Discovered "Soulcatcher"
Discovered "NO NAME!"
Discovered "Desk"
Discovered "NO NAME!"
Discovered "Lady"
Discovered "Eve Light Switch 60"
Discovered "NO NAME!"
Discovered "Tom-Tom"
Discovered "The Limper"
Discovered "TV"
Discovered "NO NAME!"
Discovered "NO NAME!"

Mac console log:

Code Block Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "Eve"
Discovered "Eve Light Switch 60CC"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "Eve"
Discovered "Eve Light Switch 60CC"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"
Discovered "NO NAME!"

Answered by ChrisMarshallNY in 622371022

I have determined that this is actually buggy behavior, on the part of Apple, and I reported it as such.

They may choose not to address it, as things become more consistent after a connection is established with the device.

However, I would argue that consistent behavior is fairly important, between different parts of the Apple ecosystem, if the same SDK (Core Bluetooth) is used, and advertisement is a pretty damn important part of BLE (Some devices, such as beacons, ONLY operate with advertisements). I could see that, if it were Core Bluetooth vs. IOBluetooth, or some other SDK, then a difference would be OK, but this is not, in my opinion, acceptable.

Additionally, the Mac inserts another field (kCBScanOptionAppleFilterPuckType) into the advertising data that is not available on other platforms.

I made the test project a lot more robust: https://github.com/ChrisMarshallNY/TestCBIssue

Boost

Answer 1

ChrisMarshallNY OP

Jul ’20

Accepted Answer

I have determined that this is actually buggy behavior, on the part of Apple, and I reported it as such.

They may choose not to address it, as things become more consistent after a connection is established with the device.

However, I would argue that consistent behavior is fairly important, between different parts of the Apple ecosystem, if the same SDK (Core Bluetooth) is used, and advertisement is a pretty damn important part of BLE (Some devices, such as beacons, ONLY operate with advertisements). I could see that, if it were Core Bluetooth vs. IOBluetooth, or some other SDK, then a difference would be OK, but this is not, in my opinion, acceptable.

Additionally, the Mac inserts another field (kCBScanOptionAppleFilterPuckType) into the advertising data that is not available on other platforms.

I made the test project a lot more robust: https://github.com/ChrisMarshallNY/TestCBIssue

0

Answer 2

wheezer_johnson OP

Jan ’21

I found your post by searching for kCBScanOptionAppleFilterPuckType, which I discovered by debugging a similar simple-as-I-could-make-it BLE scanner. My motivation is to learn about the CoreBluetooth API before embarking on a serious app development, nothing more, but the water got deep quickly.

In the documentation, there are only 8 AdvertisementKeys - CBAdvertisementDataLocalNameKey ... and so on. But my switch statement, which had a case for every key, kept falling through to the default. I start printing them to the console, and I find 2 undocumented ones: kCBAdvDataChannel and kCBAdvDataAppleMfgData. After a bit of messing about, I find that the kCBAdvDataChannel keys to a value of type NSNumber which looks like an integer, stuck at 37. The other key has a Dictionary for a value, with a single entry, with key kCBScanOptionAppleFilterPuckType. I search for that, and I get here.

Not sure any of this helps very much, but I echo your desire for consistent behavior between platforms, and add a plea for up-to-date documentation.

I'll add more here as I figure it out.

All of my stuff done on MacOS 11.1 on a 2016 MacBook Pro.

1