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.
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.
DE-TASK is a task management app (source code) that uses Firebase. Create users, locations, beacons and tasks and assign users to tasks. When users enter an area the app detects the associated beacon and they are notified about the tasks.
There are lots of Bluetooth LE scanning apps but RaMBLE for Android stands out because it does a great job of trying to identify the type of Bluetooth LE device. It also plots the detected location onto a map that can be useful for some scenarios.
The use of beacons is maturing. Instead of a product or service being all about beacons, it’s all about something else, usually more domain specific, with beacons providing a valuable adjunct that differentiates the offering.
We have been doing a survey of app store reviews of manufacturer apps used to configure beacons. Not just for beacons we sell, but for the whole industry. It’s interesting to note that there are no apps with consistently high ratings scores, on iOS nor Android. Over time, most apps seem to to gravitate towards a mediocre rating. Why?
The problems are that a) Bluetooth is wireless and hence can’t guarantee 100% reliability, all the time b) People have different technical aptitudes and some blame the software when the real cause is that they didn’t understand (or read!) c) Some phones have bugs in their Bluetooth stacks (in-built Bluetooth software).
Hence, no matter how good the app, it will end up having a number of negative reviews.
People often come to us with the wrong impression how iBeacon apps can work. They think an app can sit in the background and suddenly come to the foreground when an iBeacon is detected. If you think about it, no 3rd party apps work like this, taking over your screen, and for good reason. It’s seen as intrusive by users and both iOS and Android prevent this. Instead, apps need to show a notification which, if tapped on, goes to the app or a screen within the app.
On iOS, apps don’t actually do the detecting of beacons. iOS detects beacons with ids that have been pre-declared by the app. When an app isn’t running, iOS starts the app for only a short time to allow it to show a notification.
On Android, prior to Android 8, you could have a background service scanning for beacons. However, Android has become more like iOS. Newer Android ‘Doze’ and background restrictions mean you have to use newer Bluetooth APIs to detect beacons when the app isn’t running.
The first problem you will encounter is that few of the cross platform tools support Bluetooth. Even if they do, they don’t support it to the degree required to implicitly use the latest iOS and Android Bluetooth APIs. This is one of the main problems with cross platform in that functionality always trails the underlying native OS functionality.
Another problem is that there’s no one Android browser upon which the WebViews are based. Niels Leenheer has a (old but still relevant) set of slides that explains how browsers vary across Android versions, devices and phone manufacturers. The consequence of this is that getting any non-trivial WebView-based app to work across many device types is very difficult.
The next problem is functionality. It not only lags the underlying OS functionality in the use of APIs but also features are absent. This often requires some native coding which causes the app to become more of a Frankenstein creation with consequent unexpected complexities.