Category: iOS

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.

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

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.