Category: iOS

Apple, WWDC and Bluetooth

While some people were hoping for an ‘iBeacon version 2’ and there were rumours of a new Apple ultra wideband locating system, neither were announced at WWDC 2019. Instead, the Bluetooth news centred around the ability to use Bluetooth to find Apple devices, even when they aren’t online and even when they aren’t nearby.

Some news outlets have described this as a Bluetooth mesh network made up of all other iOS/Mac devices which is misleading and will lead to unfortunate confusion with the official Bluetooth SIG mesh. Instead, as Apple described, the system is much like the tracker ’tile’ type beacons that have apps that report in all seen beacons to a central server. If someone else’s device sees your device then you can find your device.

The difference to tile-like beacons is that the servers belong to Apple, the Bluetooth advertising is proprietary (and hence anonymous to eavesdroppers) and devices are acting as beacons. It’s interesting how, or if, Apple has done this without impacting both your iPhone battery life and the battery life of all iPhones scanning for beacons. The Bluetooth advertising must be very infrequent.

Privacy conscious people might also observe that this also gives a new way for Apple to know the location of Apple devices and proximity between devices. We wonder whether this will be ‘on’ by default for all users, opt in or opt out? Privacy matters aside, always knowing the proximity between Apple devices allows Apple to provide for some interesting possible future usecases.

UPDATE: There’s a new article in Wired explaining how the mechanism is end to end encrypted. This means Apple doesn’t know where your device is and, by implication, won’t be able to implement the possible ‘future usecases’ I alluded to.

Bluetooth LE Developer Questions

Here are the top questions we get asked as a Bluetooth LE developer:

  • For apps, can the app work without Bluetooth and location on?
    No. There’s no special OS mechanism on iOS nor Android that uses Bluetooth LE without the user having Bluetooth and location on. Many users leave Bluetooth and location on to allow ease of use with cars and audio headphones. Location is also usually one due to use with maps.
  • How does leaving Bluetooth on affect battery life?
    Bluetooth is no longer drains the battery as was the case in the early days of smartphones. It can be left on with negligible extra battery use.
  • What’s the maximum range?
    The range depends most on the Bluetooth device to are connecting to. Most devices, running on battery, work 50m to 100m. Devices with larger batteries, running from mains or USB can work up hundreds of metres. We have a device that works up to 4000m.
  • What SDK should be used?
    Most, but not all, SDKs and 3rd party libraries tend to be poorly implemented/documented, tie your code into using a particular beacon and rarely get updated to use newer mobile platform APIs. We recommend software use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type and readily able to be updated when the mobile platforms themselves are updated.

Read about our Bluetooth LE Software Development Services

SensingKit for iOS and Android

There’s a 3rd party SensingKit for iOS and Android that came out of the research, SensingKit: Evaluating the Sensor Power Consumption in iOS devices (pdf), by Kleomenis Katevas, Hamed Haddadi, Laurissa Tokarchuk of Queen Mary University of London.

While the SensingKit supports beacons, it only supports them for detecting proximity. The various sensor beacon variants are not supported. SensingKit is best used when you want the smartphone, not the beacon, to do the sensing. It’s useful when you want to mix smartphone sensing with beacon proximity sensing.

In most cases it’s best to use the native Android and iOS SDKs.

Read about our Bluetooth LE Development Services.

Android Physical Web App Removed from the Play Store

Important: This web page is provided for historical purposes.

On 25 October 2018, Google announced they are discontinuing Nearby Notifications on Android. This mechanism should no longer be used.

Read about using Beacons for Marketing

Google has removed the Android Physical Web app from the Play Store. This provided a way of scanning for Eddystone beacons without relying on the built-in Android Nearby functionality. As previously mentioned, the Google Physical web team was disbanded. Google have now removed the app, presumably because there’s no-one to maintain it in tandem with new versions of Android. Here’s the final Android Physical Web APK if you wish to side-load the file.

The iOS Physical Web app is also no longer available. The iOS version wasn’t written by Google and has recently been taken over by the non-profit Physical Web Association. 

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.

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

Bluetooth 5 in Smartphones

Last February we wrote about the progress of Bluetooth 5 in recent smartphones. A few months on and Nordic Semiconductor, the company that produces the System on a Chip (SoC) used in most beacons, has a new blog post on Bluetooth 5 in Smartphones and how we are about to experience a tipping point in support for Bluetooth 5.

The final observation from the article is:

Even if sticking to previous incarnations of Bluetooth may look like the right choice, the marketing power of Bluetooth 5, regardless of whether it’s needed or not, is likely to help companies differentiate products and increase sales.

This is true. Some companies currently claiming Bluetooth 5 support in products don’t actually use Bluetooth 5 yet but instead offer an upgrade path to Bluetooth 5.

Using Beacons in AR

There’s an interesting recent post at twocanoes on how beacons can be used to detect which room a person is in, to then run the correct AR interaction:

“While ARKit is aware of the geometry of the room the phone is in, it doesn’t know what room it is in”

Beacons solve this problem. In fact, beacons are a useful addition to many apps. The more interesting usecases are often an ancillary use rather than the main use of an app or service.

One Beacon App – Many Uses

Many existing or new mobile apps can be made more immersive and hence improve retention through the use of beacons. Sometimes, app authors add beacon detection and suddenly realise their app is also useful to totally different usecases.

One such app is Tourist Chat which started out as a travel app to allow tourists to connect. The author recently started using the same app and server side to support exhibition events.  Many beacon apps are essentially the same. They detect beacons and match this up to information in a server-side CMS. The ‘use’ or scenario can be many things: for example travel, exhibitions, hotels, retail, galleries and museums.

If you are creating a beacon-driven app, take a moment to think how it might also be re-purposed for other types of user. You might find a new market and revenue stream with relatively little effort.