I have the same problem.
In my opinion, something has changed in 10.14's CoreBluetooth that breaks previously working apps.
I'm logging from my centralManager:didDiscoverPeripheral:advertisemenData:RSSI: delegate callback.
My app initially called CentralManager's scanForPeripheralWithServices:options: passing an array with the required service 00001523-1212-EFDE-1523-785FEABCD123.
In my Mac Mini with OSX 10.13, my callback logged as follows:
2019-01-23 19:28:12.430544+0100 WAD®LS Pairing Tool[29646:1572630] LSManager: Did discover peripheral.
peripheral: <CBPeripheral: 0x6000001066f0, identifier = 48E1D646-F06E-48FF-BAD0-B0ED4BC24BEF, name = WAD_LS_261CE2EA, state = disconnected>
rssi: -61,
advertisementData: {
kCBAdvDataIsConnectable = 0;
kCBAdvDataServiceUUIDs = (
Battery,
"00001523-1212-EFDE-1523-785FEABCD123"
);
}
In my Macbook Air with OSX 10.14, my callback logs as follows:
019-01-23 19:30:48.875927+0100 WAD®LS Pairing Tool[2086:84234] LSManager: Did discover peripheral.
peripheral: <CBPeripheral: 0x600003509340, identifier = B4E115CB-C722-473D-8C76-E2FA782E4D97, name = (nil), state = disconnected>
rssi: -52,
advertisementData: {
kCBAdvDataChannel = 37;
kCBAdvDataIsConnectable = 0;
kCBAdvDataServiceUUIDs = (
Battery,
"00001523-1212-EFDE-1523-785FEABCD123"
);
}
Notice how in 10.14 name is nil, it comes from peripheral.name, which is nil in 10.14.
My app keeps a list of devices which it should connect to, and whether to connect or not is decided by name. It only connects to devices which have the required service and its name is in a whitelist.
I already have a workaround for my app to work, but it involves:
- 1) scanning without service filter, so I get device discovery callbacks for any nearby BLE device;
- 2) analysing 2 calls to the callback, the first for annotating name and the second for testing if device has the desired service.
In this post I have omitted calls to the discovery callback for many other devices, but they appear.
In my Mac Mini with OSX 10.13, both calls to the callback have the peripheral.name set to the device name
2019-01-23 18:32:59.037818+0100 WAD®LS Pairing Tool[29167:1546005] LSManager: Did discover peripheral.
peripheral: <CBPeripheral: 0x600000102be0, identifier = 48E1D646-F06E-48FF-BAD0-B0ED4BC24BEF, name = WAD_LS_261CE2EA, state = disconnected>
rssi: -66,
advertisementData: {
kCBAdvDataIsConnectable = 1;
kCBAdvDataLocalName = "WAD_LS_261CE2EA";
}
2019-01-23 18:32:59.046726+0100 WAD®LS Pairing Tool[29167:1546005] LSManager: Did discover peripheral.
peripheral: <CBPeripheral: 0x600000102be0, identifier = 48E1D646-F06E-48FF-BAD0-B0ED4BC24BEF, name = WAD_LS_261CE2EA, state = disconnected>
rssi: -67,
advertisementData: {
kCBAdvDataIsConnectable = 0;
kCBAdvDataServiceUUIDs = (
Battery,
"00001523-1212-EFDE-1523-785FEABCD123"
);
}
In my Macbook Air with OSX 10.14, the first call has the name set, but in the second call the name is nil. Notice how the device identifier is the same for both calls, which lets me know both calls are from the same device and perform my workaround.
2019-01-23 18:19:25.641195+0100 WAD®LS Pairing Tool[1945:41314] LSManager: Did discover peripheral.
peripheral: <CBPeripheral: 0x600003505970, identifier = B4E115CB-C722-473D-8C76-E2FA782E4D97, name = WAD_LS_261CE2EA, state = disconnected>
rssi: -55,
advertisementData: {
kCBAdvDataChannel = 37;
kCBAdvDataIsConnectable = 1;
kCBAdvDataLocalName = "WAD_LS_261CE2EA";
}
2019-01-23 18:19:25.641386+0100 WAD®LS Pairing Tool[1945:41314] LSManager: Did discover peripheral.
peripheral: <CBPeripheral: 0x600003505970, identifier = B4E115CB-C722-473D-8C76-E2FA782E4D97, name = (nil), state = disconnected>
rssi: -55,
advertisementData: {
kCBAdvDataChannel = 37;
kCBAdvDataIsConnectable = 0;
kCBAdvDataServiceUUIDs = (
Battery,
"00001523-1212-EFDE-1523-785FEABCD123"
);
}
It seems that the 10.14 OSX CoreBluetooth implementation "forgets" the device name in the second call to didDiscoverPeripheral.
This behaviour has broken an app which was working seamlessly, and has forced me to deliver a workaround which makes the app code more complex unnecessarily.
I think this behaviour should be fixed and reverted to previous behaviour.
Regards,
David Crespo
