On iOS 14, Apple has changed the permissions required for iBeacon region ranging and monitoring. There’s a new Precise Location permission that needs to be set to ON for the app to continue to work. Apps that granted location permissions prior to iOS 14 default to Precise Location ON after upgrading so as not to break old code.
Apps should now detect if Precise Location is enabled. Apple has unfortunately deprecated the class function authorizationStatus(). The best way of determining whether you can detect iBeacons is to examine the location accuracy.
The key thing about this research is that it uses iOS rather than a beacon to advertise iBeacon. The system allows the entire team to determine the location of other members, perform location based tasks, receive announcements and communicate via instant chat.
The paper contains some useful analysis of accuracy of distance measurement on distance, interference, measured power and obstructions:
On iOS it’s only possible to advertise iBeacon if the app is in foreground:
The major limitation of the proposed app is battery drainage while keeping the app active all the time in the foreground
A more practical system would have been implemented by having the users carry a separate wearable beacon. This would have allowed presence to be detected when the app isn’t in foreground and there wouldn’t have been a problem with excessive iOS battery use.
Nordic Semiconductor, the manufacturer of the System in a Chip in beacons and other smart devices has a new iOS CoreBluetooth Mock Library. The library allows an app to be used with dummy Bluetooth calls rather than real APIs.
The main use is for automated testing. If testing code on a server or test bed you want tests to run reliably and predictably so that you can get a pass or fail indication. Replacing the wireless part of the app allows other parts of the app to be tested.
The library also has other uses:
Taking screenshots without setting up a particular physical scenario
Developing code quicker through better repeatability
Developing code without need of a physical phone or tablet
Developing code when a Bluetooth peripheral isn’t available yet and/or is still under development
A caveat is that this library is for CoreBluetooth and not for CoreLocation. The former is intended for communication with devices that are not iBeacon. Apple forces you to use CoreLocation to detect iBeacons because they don’t provide the standard Bluetooth advertising via CoreBluetooth when seeing iBeacons.
The CoreBluetooth Mock Library is useful for detection of non-iBeacon Bluetooth devices such as fitness trackers, health monitors, Eddystone beacons and sensor beacons.
We recently started selling beacons that can advertise LINE. This post explains LINE advertising with information on the packet format.
LINE Beacons are used with the LINE messenger service that allows users to send text, video, and voice messages on smartphones and the PC. It’s currently available in Japan, Taiwan, Thailand, and Indonesia. LINE have iOS and Android developer APIs that allow you to hook into the LINE service and include LINE services in your app. The LINE beacon allows your LINE code, called a bot, to receive beacon webhook events whenever a LINE user enters the proximity of a beacon. The beacons allow you to customise your bot app to interact with users in specific contexts. There’s also a beacon banner feature, available for corporate users, that causes a banner to appear in the LINE messenger app when it comes close to a LINE beacon.
Unlike iBeacon, LINE Beacon packets have a secure message field to prevent packet tampering and replay attacks. The secure data is 7 bytes long containing a message authentication code, timestamp and battery level. Secure messages are sent to the LINE platform for verification.
LINE recommend LINE beacon packets be sent at a very high rate of every 152ms. In addition, LINE recommend advertising iBeacon (UUID D0D2CE24-9EFC-11E5-82C4-1C6A7A17EF38, Major 0x4C49, Mino 0x4E45) to notify iOS devices that the LINE Beacon device is nearby. This is because an iOS app can only see iBeacons when in background and LINE beacons can’t wake an app.
We observe that the high advertising rate and concurrent iBeacon advertising aren’t battery friendly and the beacon battery isn’t going to last long.
Bluetooth SIG have updated their Introduction to Bluetooth Beacons. It provides advice and examples how to use beacons from iOS, Android and Raspberry Pi using the respective Bluetooth APIs.
The examples show how to scan for AltBeacon which is unusual because most people will want to scan for iBeacon because AltBeacon is sent by very few beacons. This is less of a problem on Android and Raspberry Pi where slightly modified code can be used. However, on iOS, the suggested APIs won’t work for iBeacon because Apple removes the iBeacon data from the Bluetooth scan response data to force you to use the iBeacon specific APIs which aren’t mentioned in the guide.
However, the iOS and Android mechanisms are still there for more worthy applications such as visitor space usecases that need to provide location based information. For these types of application, there’s the need for good app onboarding explaining location and Bluetooth usage in order to provide the location-based information that the end-user is requiring.
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.
Pushcut, the HomeKit and workflow automation iOS app, has some updates that now allow iBeacon triggered in background. Delayed notifications and ‘do not repeat’ durations are also possible with iBeacon triggers.
Pushcut allows you to execute online actions and web requests in the background providing IFTTT triggers from an iBeacon.
We often gets asked what are the best beacons for iOS and/or Android. As mentioned in our post on Which Beacons Are The Most Compatible, all beacons, whether iBeacon or Eddystone, are compatible with iOS and Android.
The universal compatibility comes about because all beacons are slight derivations of a few standard circuit designs and firmware provided by Texas Instruments, Dialog and Nordic who produce the System On a Chip (SoC) inside beacons.
Instead, you should be looking at more physical aspects such as battery size, battery life, range, on-off buttons, waterproofing and included sensors.
There are a large number of offshore development companies currently spamming social media, claiming to do iBeacon development. We recommend you do your due dilligence before engaging development as many like to say ‘yes’ to anything and it’s often companies such as ours that have to pick up the pieces.
Here’s are some things to consider when looking for an iBeacon app developer:
Can they give examples of iBeacon apps they have written?
Can they give you references to past work who you can talk to?
Do they release development versions regularly so you can test and gauge progress? If everything is released at the end, it’s likely you are going to end up disappointed.
Who will actually be doing the development? There can be intermediaries in the development ecosystem that confuse and compound communications problems. Right from the start, you need to be talking direct with the person who will be doing the development.
Do they really understand you? Many aren’t native English speakers and if you are getting misunderstandings during initial engagement, this doesn’t bode well for the development.
Have they provided constructive comments on your proposed app rather than just saying ‘yes’? Developers should be able to improve on your ideas so as to get the best out of iOS and Android.
Getting iBeacon apps through Apple approval can be difficult. Can they give you examples why and the possible mitigations?
App development is an area where cheapest isn’t usually the best. Compromised development will cost you in the longer term through late or aborted development, tricky problems, significant end user support, poor app reviews and difficulty adapting the apps in the future for future phones and new features.
Beaconzone was founded by app developers in 2015 after we had previously created several iBeacon art gallery apps. We have since written many more iBeacon and Bluetooth LE apps on iOS and Android. Read about beaconzone.solutions