BeaconWalker Aids Solution Development

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.

Completely New nRF Connect for iOS

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.

Location Triggered Apps

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.

An example is the Photosync backup and sync app.

It has location based ‘autotransfer’ option, using iBeacons, that allows the app to accurately trigger only at a particular location.

Once beacons are added to a product, it’s often the case that new unforeseen scenarios become evident.

Manufacturer Apps

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.

iBeacon App Mechanism

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.

We offer consultancy and software development services should you need further help.

Hybrid vs Native Apps and Cross Platform Tools?

When creating apps to discover beacons, there’s often the temptation to use cross platform tools to create both iOS and Android apps at the same time. Such tools are often based on web (WebView screen) technologies and Javascript.

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.

For best performance and OS look and feel you have to use native development. It’s possible for hybrid apps to look and feel like Android and iOS but it takes a lot of effort due to the previously mentioned browser fragmentation. It’s possible to get near-native app performance by replacing (bundling) a better Javascript interpretor. However, these extra complexities are what you were trying to avoid by using the cross platform framework in the first place.

If the above doesn’t persuade you, even Mark Zuckerberg regretted using web technologies in apps in 2015. This didn’t stop others trying. There are some detailed posts on Medium explaining how AirBnB is moving back to native development and how the difficulties are not just technical but also organisational.

If you are writing apps or getting apps written we recommend you save yourself some grief and write them using native code.

Read about our development services