Category: AppDevelopment

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.

Reverse Engineering iBeacon and Eddystone Bluetooth GATT Services

For some of our beacons such the manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programmatically the UUID, major and minor, transmit power, advertising period and must rely on the manufacturer’s configuration app. While this of no consequence for the majority of uses that set and forget settings, more ambitious scenarios might want directly access the Bluetooth GATT services to change settings.

Uri Shaked has a great article on Medium on how to Reverse Engineer a Bluetooth Lightbulb. His method uses the developer logging in Android 4.4 and later to allow inspection of the Bluetooth packets and hence the Bluetooth Services and Characteristics that are being used. This method can equally be used with iBeacon and Eddystone beacons to reverse engineer the Bluetooth GATT information.

Another method is to use a Bluetooth sniffer. This listens in on the Bluetooth communication between two devices. One way of doing this is with Nordic Semiconductor’s Sniffer software on a dongle. There’s a tutorial on JimmyIoT.

It’s usually ill-advised to reverse engineer interfaces to discover undocumented features because the manufacturer can change the implementation thus breaking your solution. However, it’s very rare that firmware is ever updated in beacons and when it is, it’s usually only to fix bugs rather than change the implementation.

Integrating Beacons into Existing Systems

There are three main ways beacons can be integrated into existing systems:

1. Using Smartphone Apps

Beacons are usually stationary. Apps on users’ smartphone use the standard Bluetooth iOS and Android APIs to detect beacons and send information to your cloud or servers, typically via HTTP(S).

2. Using Ethernet/WiFi Gateways

Beacons are using moving. Gateways in fixed positions detect beacons and send information to your cloud or servers, typically via HTTP(S) or MQTT.

3. Using an Intermediate Platform Such as a Real Time Location System (RTLS)

This is a variant on #2 in that gateways send information to a system such as BeaconRTLS™ or PrecisionRTLS™. These systems have HTTP(S) APIs that can be used by your cloud or servers.

More information:
What are beacons?
Beacons for the Internet of Things (IoT)

If you need more project specific help we also offer consultancy and feasibility studies.

Working with GATT on Android

Most of the time, beacons transmit and the receiving software such as apps on iOS and Android or applications on single board computers (SBC) only read the advertising data. There’s no connection to the beacon. However, for programmatic setup of beacon parameters or accessing some sensor data, applications might need to connect via what’s known as Bluetooth GATT.

There’s an article on How to Work Properly With BT LE On Android. It provides some useful pointers such as not performing scanning and GATT connection simultaneously, avoiding auto-connect and not blocking GATT callbacks.

GATT can be unreliable on Android. While scanning for advertising data usually works very well, we have found that GATT connections fail all the time on about 5% of devices. This is due to poorly implemented OS Bluetooth software. This means beacon manufacturer-supplied configuration apps sometimes can’t connect. The only solution is to use a different phone (or the iOS version of the app on iPhone).

Caching Information in iOS and Android Beacon Apps

If you are developing a beacon app to receive unique iBeacon and Eddystone ids (as opposed to URLs), an area you should think about is caching text, images and other media.

Beacons transmit unique ids and these ids need to match up with information held elsewhere, not on the beacon, that determine what the app does and what’s displayed to the user. The problem is that in many scenarios the beacons have to be placed where the user is likely to have no or poor Internet connectivity. Poor connectivity can be as just as bad as no connectivity if larger size media such as images needs to be downloaded.

Your app and sometimes server design might need to take into account the caching of information. Some of this information can usually be bundled with the app at the time of install while information that needs to be up to date might need to be fetched ahead of time. In some cases, you might need to use a combination of the two with information bundled with the app being replaced as new information becomes available.

Here are the kinds of things you need to think about:

  • What information is included at the time of install. In the extreme case, where you think a large number of people will be foreign and roaming, this could be all your information.
  • Whether the bundled information needs to be updated at the time of install.
  • A server side mechanism to determine when information is out of date and needs to refreshed. Such mechanisms should prevent the same information from being downloaded more than once.
  • A client, app side mechanism to get notified of information updates.
  • Whether the information is updated in app background or under control of the user.
  • For optimal display of images, provision of different size images for different (screen) size devices.
  • Strategies to reduce client device resources (battery) and server stress. This might include grouping associated information that’s likely to have to be used together.
  • What the end user sees when information is being updated or not available yet.
  • If and how information eventually gets purged to save space.

A alternative to complex caching schemes is to provide free on-site WiFi. This is particularly suitable for indoor visitor spaces such as museums and galleries. This way the app can be less complex and data fetched as needed. However, remember there will always be some people who, for security reasons, won’t connect to public WiFi.

Debugging Bluetooth on iOS

There’s a new article at Bluetooth.com that explains how to capture Bluetooth packets on iOS. The PacketLogger can decode all protocols defined by the Bluetooth Special Interest Group (SIG) and Apple, perform filtering, automatically highlight problems and search and export data.

This will work for both Core Location and Core Bluetooth. Core Location is using the iBeacon APIs while the lower level Core Bluetooth allows scanning and connection to any Bluetooth LE devices, not just beacons. It’s best to use the Core Location APIs and only use Core Bluetooth for more involved scenarios not supported by Core Location.

Note that Core Bluetooth, even though it’s lower level, can’t scan the iBeacon UUD, major and minor. Apple hides these values to force you to use Core Location.

There’s also an Apple session video from WWDC 2019 explaining Core Bluetooth and PacketLogger.

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