Category: Apps

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.

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

Devices That Can See Beacons

When people think about beacons they often imagine them being detected in smartphone apps. This post explores other devices that can also see beacons allowing for different interaction possibilities and new scenarios.

Apps – Apps aren’t limited to just smartphone apps. You can run apps on TV boxes that run Android. Just make sure they have Bluetooth 4.3 or later.

Gateways – Gateways are small single pupose devices that look for beacons and send the information on via MQTT or REST (HTTP) to any server. This allows web servers to see beacons.

Desktops and Laptops – PC/Mac devices with built-in Bluetooth or dongles can see beacons.

Walky Talkies – Motorola manufacture the MOTOTRBO range of digital radios that can detect iBeacons and show their location on a map.

Raspberry Pi – This has Bluetooth and can be used to detect beacons.

AndroidThings – This special IOT version of Android can run apps that detect beacons and store and/or forward information to other devices.

Arduino – Arduino boards often have Bluetooth and can do things based on the presence of beacons.

Pixl.js – The manufacturer of the Puck.js also supplies a device with a screen that can detect and interact with beacons.

Single Board Computers (SBC) have an advantage over gateways in that data can be cached locally when there isn’t an Internet connection. They can also make decisions locally and send out alerts directly rather than having to rely on a server. This is so called ‘IoT Edge’ computing.

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.

Beware of Beacon App Generators

We are seeing more and more organisations using our beacons with apps that have been created using (online) app generation services. If you are one of these organisations then you ought to be made aware of a recent change to Apple’s review guidelines:

Section 4.2.6 states:

Apps created from a commercialized template or app generation service will be rejected

There’s discussion on this on the Apple forums and on reddit.

Whatever your or others’ view of this, Apple have already started cleaning the hundreds of thousands of titles from App Store. Beware that if you use an app generator, your app might get rejected and even if it’s accepted it might some day be taken down.

iBeacon App Development Considerations

If you are considering writing apps to communicate with iBeacons, here are some high level things you need to think about that are specific to beacon app development:

  • Detecting whether Location and Bluetooth are on/off and alerting the user for permission to use these
  • Detecting beacons in background when the iOS app is closed or the Android app is in doze mode
  • On Android, taking account of the various Bluetooth APIs that exist for the different Android releases
  • Fetching data, associated with a beacon, from a service, such that it’s cached and not fetched every time
  • Arranging for some initial data bundled with the app so that it works straight away without a data connection
  • Fetching data before it is needed such that it’s available with no delay and when there’s no network connection
  • Re-fetching of data when it becomes stale
  • Fetching metadata from the server to control the behaviour of triggering
  • Arranging how Apple will test the app for app review otherwise complications will arise and the review will take weeks
  • Assessing whether to use the mobile OS or manufacturer supplied SDKs (or both)
  • If connecting to beacons, taking account of the unreliability of wireless connections
  • Collecting and uploading statistics/analytics to assess usage
  • Providing end user diagnostics to aid support troubleshooting

Need an experienced beacon app developer to get these things done quicker? Consider our development services.

Choosing an iBeacon Developer

We are sometimes approached by companies after their initial choice of developer has let them down. The usual pattern is failure to meet deadlines after which the developer gives excuses why they can’t continue on the project. iBeacon projects introduce extra complexities that, if not experienced previously, can slow or stall projects. In the worst of cases this can cause developers to drop out wasting valuable time and in some cases loss of money that can’t be recovered.

A resultant problem is that it’s difficult to take on others’ code. The only time this is usually possible is when the developer has left for a good reason and is still around for a short time to answer questions. Noone wants to take on abandoned code as as it’s usually poorly implemented and documented.

Organisations are generally too casual about how and who they take on for development, concentrating on cost and speed at the expense of risk. Do some checking so you reduce some of the risks.

Ask who (yes a person, not a company) will be actually doing the work. How long have they been with the company? Try to assess whether they are likely to see your project through to the end. Try to get a reference for work done by the person. Ask the reference about quality and whether the work was completed on time. The better developers provide weekly or even daily builds for you to review. This allows you to evaluate progress and provide feedback. Think about how much pre-sales feedback has been received. For most projects, developers ask things and provide initial advice. If it’s all ‘can do’ or ‘yes’ then suspect something is amiss.

Successful development is a long term relationship and a random approach to choosing one is more likely to land you in trouble. It’s sometimes the case that there’s more work to be done on amendments, enhancements, solving end-user problems and creating variants than on the original development. Think longer term.

Read about our development services.