If you are developing a beacon solution it can be tricky to set up physical scenarios where beacons come and go. Peter Alt of Philadelphia Museum of Art has a useful iOS app called BeaconWalker that simulates a sequence of iBeacons with custom durations per beacon.
The Swift source code is also available on GitHub. While you are there also take a look at the museum’s mobile framework, a collection of utilities for caching data, iBeacon ranging and indoor navigation. There’s also framework demo that explains how the framework features work.
When scanning for Bluetooth devices from an app or gateway you will usually pick up lots of iOS devices.
Every Bluetooth LE device, including iOS, has a unique MAC address. MAC address randomization is used on iOS so it’s not possible to track a particular device over time. However, there have been studies that have shown other Bluetooth information can be used to fingerprint devices.
The Bluetooth advertising uses a proprietary protocol and has no use for anyone other than Apple. The advertising is used to provide for what are called continuity messages that allow handoff of tasks, such as writing email, universal clipboard, making calls from a another Apple device, instant hotspot, auto unlock from Apple watch and photo transfer between Apple devices.
An iPhone only advertises if it is associated with an iCloud account to which at least two devices are registered. Advertising can be manually turned off in the Settings Menu. Disabling Bluetooth from the Control Center does not stop the transmission of continuity messages.
It’s surprising iOS devices advertise so often, even when continuity messages aren’t being used, because it uses a lot of battery power. This must be the cost of being able to provide the app handoff messages without the user having to initiate a manual action at both ends. Maybe Apple will be able to overlay the new ‘Find My’ messages in same or similar Bluetooth advertising so as to make best use of the battery.
As we have previously mentioned, nRF Connect is the the best app for detecting if a Bluetooth LE device such as a beacon is working. The Android version has always had more features than the iOS version but that is changing. nRF Connect for iOS has been completely re-written and now has a very pretty UI.
We still recommend using the Android rather than the iOS version because iOS apps can’t see Bluetooth MAC addresses due to some peculiar decisions made by people at Apple. Scanning also can’t see an iBeacon UUID, major and minor in the advertising. It’s more difficult to uniquely identify Bluetooth devices in apps such as nRF Connect on iOS than it is on Android.
The gist of the problem is that the ‘Always’ option for allowing the location-tracking permission has become ‘Allow Once’ with the ‘Always’ option being buried in iOS Settings. People who use location (and beacon) oriented apps, are likely to select the ‘Allow Once’ option and the app will only work correctly once. This will create extra support, customer confusion and general loss of customers. The anti-competitive part comes through Apple’s own in-built apps (currently) not having to live with these restrictions.
To mitigate against the problem we recommend app authors update their apps and online instructions to explain to users to at least initially select ‘Allow While Using App’ and possibly provide more detailed instructions how to set ‘Always’ in Settings.
Beneath the hyperbolic alliteration is some research (pdf) that Bluetooth MAC randomization isn’t foolproof. Researchers have found that similarities between the non-MAC information in advertising allows devices to be uniquely identified:
“What is perhaps even more concerning, say the Boston Uni trio, is the message Bluetooth vendors are putting out to the public when they advertise Bluetooth LE as being an untrackable standard.”
In actual fact, very few vendors do MAC randomization. The majority of beacon manufacturers don’t because the whole idea of a beacon is that it can be identified via MAC address or iBeacon id. For the same reason, most Bluetooth accessories don’t as they want to be identified via apps. Android smartphones don’t do MAC randomization but iOS and Windows 10 do to improve end-user privacy. It’s mainly iOS devices that will be moving around and possibly tracked in-store or on-site via the ‘vulnerability’ described in the paper.
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.
Kiosk Pro is an app for iOS that turns an iPad into a public kiosk.
The technical documentation shows how you can trigger the showing of specific information when in the vicinity of a particular beacon. For example, if the kiosk is static, people with different beacons might trigger the showing of different information. If the kiosk is moving, for example a tablet being held, it might trigger the showing of different information based on the location of, for example, different exhibits. The kiosk can also be set to advertise iBeacon that can be picked up in iOS and Android apps.