Since the advent of the iBeacon five years ago, much effort has been spent on real-time location-based experiences through mobile. If today you were to ask “Should I develop a native mobile app?” to anyone who has invested in such efforts, you may well receive an emphatic NO. In this blog post, we’ll not only explain why, but also what you’ll likely want to use instead: the Web.
The motivation for this blog post stems from a recent presentation to a museum team who shared with us their frustration about their own real-time location-based app experience based on recent changes to Google’s Android mobile operating system. In short, the visitor experience of their museum app has tanked for Android users. This made us think back to our first ever pitch deck back in 2012:
That was before the iBeacon, and our solution, in the case of a museum, was to provide guests with a badge (equivalent to a beacon) and invite them to experience real-time location-based digital content on the Web, either through their own mobile device or a provided tablet. We helped create exactly this experience at the MuseoMix Montréal hackathon in 2014, which participants loved:
But, alas, 2014 was still a time when mobile apps could do no wrong and the Bluetooth beacon was the saviour of indoor location: our approach didn’t stand a chance. Over the past few years, countless venues and companies have invested heavily in beacon-based native mobile apps. There have been some brilliant successes. But most of the veterans we’ve encountered of late have been underwhelmed and battered at best.
What have Google done to beacon-based location in Android?
— A frustrated colleague, Sept. 2018
And now this latest incident where significant changes to Android caused panic among many of our colleagues, partners and clients! For many, beacon-based mobile location experiences went from passaBLE to terriBLE. Case in point: the museum. What were Google thinking? In a recent post we speculated whether Google might have “something revolutionary up their sleeve”. Could that something be… …the Web?
Could Google be thinking web-first about mobile indoor location?
One might not be aware, but Google’s Chrome browser has supported Web Bluetooth for some time. For instance, you can program a Bluetooth Low Energy (BLE) device wirelessly from the browser! Yet surprisingly, Chrome support for the comparatively simple — yet immensely powerful — feature of scanning for all nearby BLE devices has been relegated to the “What’s Next” list for years now.
Is this due to a technical problem? Doubtful.
Is this due to a business problem? Likely. The scan feature would make beacon-based native apps, and all their behind-the-scenes business models, largely irrelevant.
But wait, Google DID just made beacon-based native apps largely irrelevant…
If, unfortunately, the scan feature were to remain pending indefinitely (one can check if/when it works here), in most cases today, the most economical and reliable solution nonetheless is that which we initially championed: provide users a $5 beacon-badge for real-time location and retain the mobile device merely as an interface (web or native). $500 rectangle meet $5 rectangle indeed!
And while the astute reader will exclaim “but what about the cost of the Real-Time Location System (RTLS) infrastructure!?!”, we’ve noted of late that a BLE RTLS may well cost considerably less than the development and maintenance of a beacon-based native mobile app! Moreover, a BLE RTLS (like our own) simultaneously supports both the Web Bluetooth and RTLS approaches.
Coming back to Google, our cautious optimism about a potential shift to web-first mobile indoor location stems from the presence of Vint Cerf, their vice-president and Chief Internet Evangelist, who, in 2015, shared the following three-pronged approach to the Internet of Things, which would indeed be consistent with such a strategy:
Regardless of what Google might have up their sleeve, if today you find yourself asking “Should I develop a native app?” to meet a need for mobile indoor location, in most cases the answer is clearly no. You should use the Web. It remains the penultimate “interoperable ecosystem based on open standards”, and no single vendor will be able to do away with it on mobile.