capacitor-community/bluetooth-le

iOS 16.4.1 - scan not returning a local name

ASHBAW opened this issue · 6 comments

ASHBAW commented

After updating an iPhone to 16.4.1, which was released a couple of weeks ago, I noticed that after performing a scan that the scan is not returning a local name.

Is anyone else seeing this issue?

ASHBAW commented

Here is some additional information. We have a default device name - 'Hickory'. This is currently what is appearing after a scan with the plugin in our app with iOS 16.4.1. We set the local name to the serial number of the device. This serial number is what has been displayed after a scan with the plugin in prior iOS versions.

When I use a "generic" Bluetooth app (Light Blue) on an Apple device I get the following:

pic1

As you can see it has a serial number in the local name. This is the expected behavior.

If I set a breakpoint in Xcode within the plugin's getScanResult() function I get "nil" as the result of the local name, not the serial number - 2619W0589 I get with the generic Bluetooth app.

Screenshot 2023-04-25 at 8 30 06 AM

If I use an Apple device with an older version of iOS I get the correct local name 2619W0589:

Screenshot 2023-04-25 at 8 38 59 AM

Any insight as to what can be done to get this functionality working as before?

Thanks,

Brent

On my side, the local name is present, but after the update to iOS 16.4.1, the manufacturer data is missing. Tested on another phone with iOS 13.x and there it worked. After the update to iOS 16.4.1 the already mentioned issue appeared as well on the other device.

image

ASHBAW commented

I had posted to several forums. about this. One suggestion was to add scan option - allowDuplicates.

Normally scans will discard the second and subsequent advertisements from a single device. If you need to receive them, set allowDuplicates to true (only applicable in requestLEScan). (default: false)

It works, though you get duplicates as per the flag.

Not sure why this would work?

I can confirm that I see this issue on some devices, but not others. I think it might be related to how iOS caches BLE Devices. On iPhones that had scanned the BLE device before I do not have this issue (and #528). The issue only occurred on devices that did scan the device for the first time.