Category: CoreLocation

Debugging Bluetooth on iOS

There’s a new article at Bluetooth.com that explains how to capture Bluetooth packets on iOS. The PacketLogger can decode all protocols defined by the Bluetooth Special Interest Group (SIG) and Apple, perform filtering, automatically highlight problems and search and export data.

This will work for both Core Location and Core Bluetooth. Core Location is using the iBeacon APIs while the lower level Core Bluetooth allows scanning and connection to any Bluetooth LE devices, not just beacons. It’s best to use the Core Location APIs and only use Core Bluetooth for more involved scenarios not supported by Core Location.

Note that Core Bluetooth, even though it’s lower level, can’t scan the iBeacon UUD, major and minor. Apple hides these values to force you to use Core Location.

There’s also an Apple session video from WWDC 2019 explaining Core Bluetooth and PacketLogger.

Using Beacons with iOS 13

iOS 13 has introduced changes to Location and Bluetooth permissions. Estimote has an excellent new post summarising the changes and their affect on apps using beacons.

The article differentiates between Core Location and Core Bluetooth. Core Location implies using the iBeacon APIs while Core Bluetooth is lower level and allows scanning and connection to any Bluetooth LE devices, not just beacons (but perversely can’t scan the iBeacon UUD, major and minor). If, as we recommend, you use the Apple Core Location APIs directly, only the Core Location permission changes will affect you.

There was time, during the release of iOS 10 when Core Location beacon detection was faulty. At that time, Estimote decided to create an alternative beacon detection API based on Core Bluetooth to circumvent the problems. This means that if you use their SDK, users of your apps will get both Location and Bluetooth prompts and both permissions are required for the Proximity SDK to function. The iOS 10 triggering problems have since been fixed.

Apple Tag – a Tile-like Device

In our previous post on Apple WWDC on the ‘Find my’ feature we explained how the use of others’ phones for finding your devices is much like Tile (and other tracking beacons). However, there’s evidence that Apple might also be creating their own, separate, Tile-like device. 9to5Mac also have some further speculations.

It’s also interesting that Apple are changing the API for looking for beacons. CLBeaconRegion has become CLBeaconIdentityConstraint. The functionality currently remains the same in that you can filter by UUID/major/minor. However, the renaming of the API to make it more generic suggests it might eventually also be used for something else which might be the Apple tag.

While devices such as the Tile are great, when finding items remotely, they assume lots of people have them for someone else’s Tile app to see your tile. While the Tile network is large at 15 million trackers it will never be large enough to reliably find things. Apple has a much greater reach to make such a scheme more successful. Tracking things such as your lost car or dog become far more feasible.

An observation is that Google Android has a substantially greater reach offering Google the opportunity to offer something similar, more reliable (due to sheer number of devices) but more open as they did with Bluetooth Eddystone vs iBeacon. Taking this idea further, it’s a shame there isn’t an open Bluetooth tracking system or standard, for example, championed by the Bluetooth SIG.

September 2019 Update: It’s looks like Apple will be using UWB rather than Bluetooth making the solution more accurate and more proprietary. If true, it will eventually compete with Bluetooth Direction Finding.

May 2020 Update: The device will be called AirTag.