WWDC 2016: iBeacon and Apple’s Last Chance

Google is cleaning Apple’s clock in proximity. Their suite of software development tools leaves Apple in the dust – from tight integration of their Nearby API and their Eddystone beacon protocols, to the monumentally important physical web, Google is making sense of proximity.

It didn’t need to be that way. Apple was first out of the gate with the iBeacon protocol. They had ample opportunity to take it further.

But a few World Wide Developer Conferences later, and iBeacon is the orphan child of Cupertino – filled with vague promises never fulfilled.

The only hint of iBeacon heading in a new direction was the announcement that you would soon be able to deliver “Offers” . But the project was abandoned when Apple killed iAd. (And the link to the Apple announcement has long been dead).

The Mistakes Apple Makes

The launch of iBeacon promised to revolutionize how our phones would react to the world around them. Apple launched it with little fanfare and yet it prompted a wave of hype – the promise that retailers could reach consumers with coupons, that museums could display digital data “next to” a painting or sculpture, or that we could track down friends at a club because their phones would be broadcasting as beacons.

The initial problems were understandable. A new way to “listen” to nearby devices was bound to have a few bumps. And you’d expect over time that Apple would continue to enhance and improve the technology.

But after several years, the changes have been minimal. And in some ways they’ve perhaps even degraded.

The technology itself, however, wasn’t the only problem:

  • iBeacon was a trademark for beacons, but Apple offered little value in the iBeacon brand. You could adopt the iBeacon mark – or not. There was little incentive for beacon manufacturers to proudly wave the iBeacon flag, because it offered little assurance to end purchasers. Sure, it said that “this beacon can be heard by iPhones” but this caused more of a limitation than an opportunity – because the obvious next question was “What about Android?”
  • Apple lawyers got in the way. The company aggressively protected its ‘iBeacon specification’. But the move was kind of like trying to protect a proprietary version of WiFi – it’s a technology everyone needs to use, and by ‘blocking’ access it created market confusion and all kinds of end-runs around the iBeacon standard.
  • iBeacon detection became (even more) unpredictable. With every new OS release, you’d have to test all over again. The dependability of beacon detection kept changing. With one release, you would detect beacons quickly, and with the next O/S it seemed as if Apple was trying to conserve battery and had toggled back beacon monitoring. Without the ability to dependably say how long it would take to detect a beacon, and without being able to see ‘under the hood’ developers were faced with constantly checking their assumptions about beacon detection every time a new version of iOS was launched.
  • There was little integration with other parts of the Apple ecosystem. Have you ever tried to register your “place” with Apple? I can barely find the page. Google, on the other hand, offers much deeper integration with other parts of their ecosystem – in part because of how far ahead they are on things like maps, places, nearby and other protocols.

But perhaps more than the above, Apple neglected the one thing that it does best: focusing on the end user.

Instead, it has allowed app developers to make what they will of iBeacon and BLE, while offering little guidance on how to create great consumer experiences. As a result, we’ve seen struggles in develop “hits” – apps where consumers truly get a ‘wow’ factor.

This isn’t solely Apple’s fault, of course. Instead, the company has focused on other broader experiences – and will perhaps one day bring iBeacon back into the fold.

Physical Web is a Game Changer

Google, on the other hand, looked at the experience of proximity and has created beacon-detection tools that make sense – the Eddystone protocols are well considered, have rich documentation, great examples, and tight integration with other services.

But the true game changer is the Physical Web. And while it’s early days, the Physical Web creates opportunities for user experiences that truly make a difference – by hooking proximity into the web itself.

With the shift to browsers that can detect and control all kinds of BLE devices, the Physical Web is one part of a larger shift to a Web which reacts to the physical world – and in this open world Google will always be master.

The tension between open and closed systems will continue to tug and pull, but for right now open is winning and Apple is left behind.

WWDC – What’s Next?

All of which leaves Apple with one last chance – to elevate iBeacon from orphan child to star of the show.

If Apple makes a move, it won’t be to enhance the ability to deliver coupons. It will be part of a larger ‘connected space’ strategy which may incorporate Apple News, Music or other products.

But it’s a last kick at the can for Apple, in my opinion. Because depending what approach they take at their Developer Conference in a few weeks, developers may well migrate to a “Google-only” proximity strategy (including the use of Google tools on Apple devices).

It’s up to Apple, as they have many times before, to take what others have done and make it their own. But in this case, the mistakes they need to learn first are their own.

Share Your Thoughts

Join our e-mail list for more on iBeacons, Eddystone, Physical Web and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Do you think Apple can change the game? Or will Google now dominate proximity? What could Apple do next with iBeacon – or is it too late? Drop a comment below, or pop me a note on Twitter.

Kontakt to its Customers: You’re All Doomed


Kontakt, one of the largest manufacturers of beacons, has a message for its customers: you’re all doomed.

In what might rank as one of the more bizarre examples of corporate messaging, the company’s founder has taken to LinkedIn to pronounce that with the arrival of the Eddystone beacon protocol (and related services) by Google, proximity companies are headed for the dust bin if they don’t radically change (and soon).

“Ask not for whom the bell tolls, proximity devs: it tolls for thee,” proclaims Szymon Niemczura.

But extending the logic of Szymon’s article, you can’t help draw the conclusion that it isn’t just the devs who will pay the price for Google’s entry into the market.

If you’re a retailer, a brand, a museum, a car company, a city or a theme park – you too should just throw up your hands and give up now.

Google will own mobile moments, the borg has arrived, and closed off becosystems will look something like AOL in the years to come: a walled garden that no one visits anymore.

And Apple? Naw. Says Szymon:

With a vanishing share of the smartphone market, the last thing the house that Steve built wants to do is give developers even more reason to jump ship.

Ah yeah. Poor Apple. Poor shrinking tiny little Apple. It’s hard to remember that they’re still around! It will be cute to see what little features they try to throw at us to protect their ever-vanishing market share and profits.

What’s Your Secret Sauce?

Now, I like Kontakt. They’re some really really smart people.

(Although, what’s with the videos that look like they were shot at summer camp? And by the way – audio engineering is a thing).

So maybe they have a secret sauce as Szymon claims: “At Kontakt.io, we think we’ve found our special sauce that will keep us growing and thriving as giants of the Internet space like Google, Apple, Facebook, and others compete over who earns what from the IoT.”

In response to which I have a question: China?

Because if Szymon’s observations are true, then the beacon itself has become king. The app layer, the SDKs and the software, the cloud services and back-end analytics will be swallowed up by the Web.

The promise of Eddystone is that you can turn your beacon into a Web endpoint and simply broadcast a URL.

And if that’s true, then it opens up the opportunity to flood the market with cheap beacons from China that do nothing more than broadcast a URL.

Do You Jump Into Bed With Google?

Setting aside the tone of Szymon’s article, it points to a larger question.

Because what’s clear is that Google has hit a home run. Eddystone is everything a beacon should be.

Google took a page from the Apple playbook: wait for the industry to develop, cherry pick the best ideas, and then come out with something that does everyone else one better.

The Eddystone format is brilliant.

But now you need to make a decision: do you go “all in” with Google, do you try to find a middle ground, do you focus on the “app-less” layer or combine different proximity experiences to create a unified customer journey?

Creative Tensions Between Open and Closed Systems

The way you answer the above questions will have a big impact on what kind of beacon you buy and what kind of customer experience you want to create.

In an interview with Kontakt, they clearly think that the “app-less beacon world” is a big deal:

Along with yesterday’s release of new Chrome browser for iOS with support for a Physical Web standard this became clear – proximity devices are able to communicate with our phones without the need for other apps. This means a Physical Web is finally visible and ready for broader adoption.

But here’s the problem: what does “communicate with our phones” mean?

Is that all we really want to do? Is your vision of the mobile world one in which the Web has won?

Szymon is right:

“10 years in Internet is effectively forever, and it’s a rare startup that considers what the landscape will look like as far out as two years, but this matters, so I’ll point it out: native capacity to push alerts and more direct from beacons to devices kills a huge number of app use cases.”

Truly, the traditional definition of an “app” is eroding.

There will be apps that sit on your phone but that you’ll never use on their own. Instead, they’ll be shared as ‘sheets’ inside other apps, provide deep linking capabilities, and sit as a kind of invisible thread across an ecosystem of experiences.

But that doesn’t mean that apps will be replaced by whatever Google has to offer, anymore than it means that HTML will win in the war against native.

Which is why Eddystone does more than just broadcast Web pages (although its ability to do so will open up some pretty great user journeys).

Like many engineers, Kontakt seems to be more interested in the transactional nature of systems than the very real human experience they entail.

(Just look at Kontakt’s Web site or its developer portal and you’ll see what I mean – they feel like were designed in 2002 by a bunch of engineers one weekend).

The implication here is that in the tension which will always exist between open and closed systems, the pendulum has swung: open will win, Google is right, native is disappearing and apps are dead.

If you’re willing to make that bet, great. Go for it. At least you’ve taken a stance! And perhaps in the longer arc of history you’ll be right – but until then we still have to worry about today.

What Kind of Beacon Will You Use?

In response to questions about Eddystone, Kontakt tells me that you’re going to need to make a choice (at least for now) in which of their beacons you choose: Eddystone OR iBeacon.

Why? Because battery.

In an interview, Kontakt tells me:

Our beacons broadcast 4 different frames one after the other: 3 advertising packets (Eddystone-UID, Eddystone-URL, Eddystone-TLM) and a scan response. To the best of our knowledge, Kontakt.io is the only company on the market who has offered that from day one.

We have been investigating the possibility to add also an iBeacon frame to the set, but broadcasting that many different packets is going to cause a pretty heavy battery drain. While we research ways to help keep a useful battery life on our product, we will also be looking at client demand for this feature. We don’t have any timeline on when we may roll this out, as it’s very much just in R&D right now.

Which is odd, considering that if you don’t interleave with iBeacon, then your beacon battery might be fine, but the iOS user’s won’t be. By relying on Core Bluetooth instead of the native framework from Apple, you can expect Apple users to take a hit on battery life if you’re solely relying on the Eddystone format.

These kinks might be worked out, but it’s an obfuscation to say that it’s your beacon’s battery which is the sole limitation.

In fairness, Kontakt isn’t entirely advocating a “throw out your iBeacons” stance. If you’ve got some of those old beacons lying around then sure, why not, you should hang on to them. (But I guess you should know that you’re missing out on some huge potential):

Every discussion regarding iBeacon and Eddystone formats, and which one fits our client needs better, always starts with a question about use case details. Eddystone opens new possibilities, but at the same time requires more complicated coding to integrate as it sends more types of data than iBeacon does. Beacons that use Eddystone-TLM format to send telemetry data (such as temperature data) will have shorter battery life because they are sending more data packets etc. All of that needs to be taken into account before we jump on the Eddystone bandwagon.

In general, I think that “switching” is probably not the correct choice for anyone with a live deployment right now. Anyone with a P.O.C. that’s running, though, or someone who’s in early tests? I would strongly encourage that those people try this out because this whole platform is growing in exciting ways and has huge potential.

For many use cases, an Eddystone URL format beacon might be fine. You might be able to move the needle a bit on customer engagement.

For everyone else, there are larger questions at stake.

Kontakt itself hints at this future. With the coming wave of mesh beacons, the company’s Cloud Beacon takes aim at what will happen when the next Bluetooth specification starts hitting the market. The company tells me they have big plans, and that those plans validate why its Cloud Beacon format isn’t threatened by Google’s Proximity API:

Our Kontakt.io Cloud Beacon remains the only enterprise-level tool for beacon monitoring that we’re aware of: if you need to be able to guarantee that you are scanning and looking at beacons in a given area at regular intervals, a Cloud Beacon is your best bet. On top of that, Cloud Beacons are part of our other real competitive advantages: security and sharing.

In the future we will introduce completely encrypted channels for communication between beacons, cloud beacons, and smart devices. This, combined with powerful features such as our scheduled profile shuffling (driven by our API) and the industry’s only Power Sleep mode designed to extend beacon battery life, means that the Cloud Beacon still has very strong USPs that make it an attractive prospect for any company looking to roll out beacons on the large scale.

An Industry Transformed

The industry has been transformed with the launch of Eddystone.

For beacon manufacturers, a new wave of low-cost alternatives from China will put pressure on them to tighten up the value-added services they provide, the relationships they have with developers, and the level of execution they put into their user documentation, community management and marketing.

For developers, the range of opportunities has expanded rather than contracted.

But while Eddystone might seem to cut through the clutter and remove barriers in app development it also creates a richer, and thus more complex suite of choices for brands, retailers, cities and cultural institutions.

I have deep faith in this industry.

I don’t need to give any of you a wake-up call or tell you that you’re doomed. Because for the 100s of proximity companies I’ve talked to, and for the hundreds of brands and retailers we’ve interacted with (and who are doing their best to make sense of a rapidly changing world), I’ve found that optimism in the face of progress is the best guarantee of innovation.

And this week, we’ve entered a new era in which to thrive.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

How will you respond to Eddystone? Is this a new era of doom or one of innovation?

Google Updates Terms of Service for the Physical Web

Google has updated its Terms of Service for Chrome to clarify the use of the browser as part of the “Physical Web“.

The update, which coincides with the release of beacon detection in Chrome browsers for iOS (with Android support expected in the coming days), clarifies that users won’t be sharing personally identifiable data from their device when they connect to a beacon that broadcasts a URL.

Specifically, the update, which went live on July 21st, informs users that:

If you enable the feature in your device’s Today view, you can use Chrome on your iPhone or iPad to discover objects around you that are broadcasting web addresses as part of the Physical Web. When you use this feature, Chrome sends the web addresses broadcast by these objects to a Google server to find the title of the web page and help rank the results. The information sent to Google to provide this feature does not include any personal information from your device.

Now, it’s not to say that Google isn’t using the data about which URLs are being pinged, and you need to consider your use of location services as well:

If you use Chrome’s location feature, which allows you to share your location with a web site, Chrome will send local network information to Google Location Services to get an estimated location. Learn more about Google Location Services and enabling / disabling location features within Google Chrome. The local network information may include (depending on the capabilities of your device) information about the wifi routers closest to you, cell IDs of the cell towers closest to you, the strength of your wifi or cell signal, and the IP address that is currently assigned to your device. We use the information to process the location request and to operate, support, and improve the overall quality of Chrome and Google Location Services. The collected information described above will be anonymized and aggregated before being used by Google to develop new features or products and services, or to improve the overall quality of any of Google’s other products and services.

But the update is welcome news on the privacy front.

It might not solve the problem of beacon spam if we’re suddenly flooded with millions of the little devices as we wander around the neighbourhood, but it’s somewhat assuring to know that Google isn’t sending personal information back to its servers just because your Chrome browser heard an Eddystone beacon as you walked through the mall.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Google Eddystone Jumps into the Browser on iOS


Your browser will now connect to ‘cookies’ in the physical world – beacons, which can now broadcast a Web URL as part of Google’s new Eddystone protocol.

And Google is planting its flag on iOS devices first.

By launching beacon support within Chrome, Google is effectively bypassing the gatekeepers at Apple and providing support for beacon detection “without an app” – because the app is the browser.

Having said that, Google won’t exactly be spamming you with messages. Instead, if you’re near an Eddystone beacon, you’ll need to be using the Google Today widget in your notification center (or it will need to be refreshing).

And yet, by planting this flag in iOS, Google has a relatively confined audience to test the Physical Web – and bringing that capacity to Android (in, perhaps, a far richer format) isn’t far behind.

While the percentage of users who have installed of Chrome on iOS devices isn’t known, it’s not insignificant, and likely ranges somewhere around 10%+, representing 10s of millions of users.

The larger win will be when Google launches similar support for Android, likely in the coming days.

But beyond the installation numbers is something perhaps even more compelling – because with beacons, Google will have a way to conceivably “ping you” to open a Chrome browser that you rarely use. While not currently how they’ve designed it (they limit the notices to an active Notification Center view) it won’t be long before they take the functionality further.

Google Goes Out for Launch

It took a while, but Google launched a full beacon development framework this past week. The framework included the open source Eddystone specification for beacon broadcasting, along with a host of tools and integrations.

The project was a grand slam, perhaps shockingly so, (depending on your view of how well Google promotes itself and how well it handles documentation and design).

Apple launched its iBeacon framework with barely a whisper at its World Wide Developer Conference in 2013. It then did very little to evangelize or explain the technology and created endless market confusion (perhaps intentionally), both over what an iBeacon actually IS, how it differs from the Apple software SDKs, the difference between an iBeacon and BLE, and how it would integrate across the larger Apple ecosystem.

Since then, Apple did very little to expand the protocol. It added beacon support to Passbook, thus allowing “app-less interactions”, and it recently announced it would further extend engagement through Apple Wallet and its iAd platform.

But Google has taken a page from what you might typically think of as the Apple playbook – creating a tightly integrated system of software and services to allow rapid development and deployment of a new technology.

Additionally, it did pre-launch outreach to a few select companies, who are now beating the drums as if they’ve joined the Google empire, and it managed its press relations, publicity and self-promotion as if Marissa Mayer still worked there.

And now, its followed up the success of the Eddystone launch by planting its flag inside iOS, letting the Chrome browser detect beacons and pushing you messages even in the absence of what you normally think of as an ‘app’.

The Physical Web

What makes this possible is the unique broadcasting packet of the Eddystone beacon protocol, called the Eddystone-URL. It allows you to:

  • Broadcast a URL from your beacon instead of an ID number
  • By broadcasting a URL, you can bypass the need for an app to “parse” the meaning of a beacon’s unique ID number
  • You can thus leverage existing Web resources and simply point the user to a Web URL
  • With this capability, the potential to bypass the app layer entirely is made possible, and with Google now launching support via Chrome, you’ll be able to pop a “URL beacon” on your wall and let the Web do the rest

Back to Basics on Beacons

For those who are just joining us, a beacon is a relatively ‘dumb’ device that is based on an open Bluetooth specification. A beacon broadcasts a signal, and when your phone “hears” that signal, it can act on it.

In a traditional beacon, the signal typically consists of a unique identifier and a bunch of extra ‘keys’. When your phone (via an app) hears this identifier, it can make a decision on how to act, usually by referencing a cloud-based service which provides it instructions on what kind of content to display.

Eddystone, however, incorporates the Physical Web as one of its broadcast signals.

The Physical Web was originally one of those “in my spare time” projects at Google (most of which remain experiments and are never brought into its main business). The premise of the Physical Web was simple: rather than build a NEW infrastructure for beacon content, why not just leverage Web development?

By broadcasting a URL, your “app” wouldn’t need to go to a cloud server or otherwise parse the meaning or purpose of the ID number that the beacon broadcasts. Instead, you can just open a browser.

Eddystone lets you broadcast a URL (it also has more “traditional” beacon broadcast formats, which are still needed for richer/native type app experiences) and it’s this capacity which makes Chrome the natural choice for broader “beacon detection” without the need for an app.

The Pros and Cons for Retailers and Brands

As I wrote yesterday, Eddystone is a big win for anyone who wants to create some kind of interaction with consumers based on proximity.

It’s just a beacon, after all, and by producing a robust suite of software tools for Android, we now have an easier and better way to deploy beacon experiences to Android devices.

But beyond the beacon itself, there will be some strategic decisions to make.

Because Google didn’t just launch beacon support. It also launched a suite of accompanying APIs and integrations – and whether you decide to use them will have as much to do with your views on who owns and should monetize the data in your venue and about your customers, and how important it is to achieve new ‘reach’.

Integrate with the Physical Web and your customers are now using a Google product and that product will now have access to data about where your customers are and what kinds of “physical world Web sites” they’re connecting with (although it promises not to share any personally identifiable information from your device).

Integrate with Places, Nearby or its Proximity API and there are other decisions to make.

But this all points to a larger message: that the tools for reaching customers have just become richer, that the era of the app as the primary driver of mobile engagement is coming to an end. You’ll now have more and more tools to reach consumers based on proximity and that’s a very good thing.

And, strangely, and for today anyways, if you want to test out Google’s Physical Web, you’d better get out your iPhone first.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Well….wow huh? What do you think? Call me impressed.

Google Loves Apple (In a World of Beacons)


 

The launch of Eddystone by Google has, at long last, addressed a challenge in creating proximity experiences with beacons. Namely, that the software tools for beacon detection and interaction were less robust for Android development than for Apple devices.

The media narrative, as always, paints the move by Google as a showdown between Eddystone and iBeacon.

Mashable calls Eddystone a rival, Ars Technica announces that iBeacon needs to move over because Eddystone is a fighter, and Tech Republic concludes that it has clear advantages in the showdown with Apple.

Now, you can’t blame the media. It makes good copy.

If Google launched some kind of self-driving toilet paper the media would call it a rival to the iPad, siphoning off valuable screen time from its arch enemy in Cupertino.

And while there’s a broader truth to the Apple v Google narrative (which I’ll get to in a minute), the truth is that the move by Google has made life easier for brands, retailers, developers and device manufacturing companies.

What Your Clients Need to Know

If you work in mobile development you’ll know that the last thing your clients need to hear is that there’s yet more fragmentation – between Android devices, between Apple and Android.

The good news is that, at the simplest level, Google’s announcement of the Eddystone beacon format (and the accompanying development tools) means that we can now create beacon experiences for both Android and Apple devices in a way that assures a higher level of confidences that the experiences will be on par.

Better yet, Eddystone has added a few tricks to how beacons work that will benefit both Apple and Android apps. These tricks include the ability to embed beacon management functions inside your app (instead of needing to rely on some type of admin app or cloud beacon), a promise of increased beacon security, and the ability to link beacons natively to web URLs.

By launching an open specification and leveraging the capacity of beacons to interleave multiple signals, brands, retailers and venues can get the best of both worlds:

  • Android apps that respond as fluidly to beacons as Apple apps
  • Access to new beacon features across both platforms
  • No need to buy new beacons – especially if your hardware provider is one of Google’s preferred manufacturers (and we note that almost all of them are our own!). Just update your firmware and you’re good to go.

There’s No App For That

The second part of the media narrative about Eddystone is its capacity to deliver a URL in place of a unique identifier. The promise is that on Android, you’ll be able to deliver messages without an app.

Part of this promise will be reliant on what Google releases with Android M so it’s too early to judge how deep this promise will go. We’ve long speculated that the secret war horse for Google will be Chrome – a trojan horse on Apple devices that could conceivably contain beacon detection and help Google bypass the gatekeepers in Cupertino.

Regardless, the capability of reaching consumers without an app isn’t confined to Google.

Apple has been using Passbook to trigger beacon interactions and will be extending this through Offers, a new iAd “wrapper” on Apple Wallet. We assume that this will allow brands to target iAds based on location and allow the delivery of Wallet Offers (similar to Apple passes) which embed beacon detection (as previously available).

So while it’s a compelling value proposition – the ability to bypass apps entirely, it’s not confined to Google.

Who Owns The Experience?

It’s when we look beyond the beacon that the Google v Apple narrative starts to make a bit more sense.

Both Apple and Google give you tools to register your “place”. Both want to help you map your indoor location. Both want to provide “contextual experiences” through Siri, Google Now, and search.

And both want to serve ads:

  • Google wants to use all the data it can get to serve better (and more) ads across more platforms (including iOS)
  • Apple wants to generally keep the data anonymous but still wants to make money through its iAd platform.

Apple’s main focus is the user experience, and we can expect to see more and more tools to integrate beacons into payments, Apple Wallet, in-home connectivity, and location-based context. Google’s main focus is giving users better and better free tools and applications but in the larger service of ad revenue.

Neither approach is bad for brands or venues. But each provides strategic pros and cons – from sharing your data about your customers with Google through the lack of access to individual user data on the Apple platform.

But these trade-offs and decisions have nothing to do with the beacon. The choice to integrate that beacon, to make Google aware of its presence, to integrate it with Google Now (with the benefit of “app-less” consumer interactions but with the cost of providing Google data about your customers) are strategic ones.

As a retailer, you’re faced with the same questions you’ve already struggled with: who owns the data about what happens in your store, and are the trade-offs worth it?

But, again, those questions have nothing to do with the base function of the beacon, and are supplemental decisions about how far you want to go with Eddystone.

For now, it’s enough to know that beacons just got better, and users of both Apple and Android devices will benefit from the innovation.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

What do you think? Google has clearly done Apple one better with Eddystone. But is it really a “threat”? How will you use Eddystone?

Tutorial: Using Beacon and iBeacon Technologies on Your iPhone / iPad with PubNub | Guest Post

iBeacon has been quite a buzzword since the release of iOS 7 when Apple enabled all their iPhones since the 4S with this new BLE technology.

The iBeacon is simply a protocol that takes advantage of the new Bluetooth Low Energy technologies. It has been easy for companies, aside from Apple, to emulate similar protocols such as estimote or AltBeacon. As a result, we thought iBeacon and PubNub could fit together in some pretty cool ways.

In this article, we will explain how the iBeacon protocol works by taking a closer look at how the emitted data is actually structured. We will move onto how to use the iOS sdk to detect and emit beacons. Finally we will try to see if we can use other protocols on iOS devices.

 

iBeacon Detecto
iBeacon Emitter

 

What an iBeacon’s Advertisement Looks Like

According to the Bluetooth v4 specification, a beacon advertises a data package called the Scan Response Data.

This Data can be up to 31 bytes. If we create a smaller scan response, the remaining bytes will be filled with as many 0s.

The scan response is divided into what are called AD structures. They are sequences of bytes of various size, with a predefined structure that goes as follows:

  • The first byte represents the number of bytes left to the end of the AD structure. This allows a receiver of this structure to know when it ends and when a new AD structure starts.
  • The second byte is the ID of an AD structure type.
  • The rest of the bytes are data that is structured in a predefined way depending on what AD type was defined by the previous byte.

That’s all there is to it. Just a succession of AD structures.

Most beacon protocols have only 2 AD structures, which are as follows.

The first one has 3 bytes:

  • The first byte will be: 0x02 because we only count the following bytes.
  • The second byte is: 0x01 which indicates we have a “Flag” AD type.
  • The last byte represents theses flags. These flags express whether the emitting device is, in “Limited Discoverable Mode”, “General Discoverable Mode”, etc… The byte is computed the following way:

The 5 flags are represented by the first 5 bits of a byte. The value of these bits defines whether the flag is ON or OFF. The binary number is then written as a hexadecimal value which will be advertised. An example may clear things up:

bit 0 OFF LE Limited Discoverable Mode
bit 1 ON LE General Discoverable Mode
bit 2 OFF BR/EDR Supported
bit 3 ON Simultaneous LE and BR/EDR to same Device Capable (controller)
bit 4 ON Simultaneous LE and BR/EDR to same Device Capable (host)

The resulting binary value hence becomes: b00011010 Converted into a hex, we get: 0x1A

That’s all there is to the first AD structure! Let’s look into the second one, which contains most of the information we need!

 

image00

 

The second structure can be of a different size according to the protocol. Let’s look at the detected scan response emitted by an iPhone.

  • First byte is 0x1A (26 in hexadecimal).
  • The next byte is always 0xFF which means we have a “Manufacturer Specific” type of AD structure.
  • As a result, the 2 following bytes represent the company identifier as defined on bluetooth.org. For an iOS device, the manufacturer is “Apple Inc.” whose company ID is 76. In hexadecimal value, this is equal 0x004C. The ID, written as little endian, takes up 2 bytes. Here it will be 0x04C 0x00 in this order.
  • The rest is Manufacturer specific data.

For the iBeacon protocol, the 2 first bytes of the manufacturer specific data are always 0x02 0x15. The next 16 bytes are a UUID representing the advertiser’s organizational unit and the 4 following bytes are going to be the major and the minor. They are 2 bytes long numbers.

There is a final byte at the end of the data structure called the TX Power, which represents the device’s signal reference intensity a meter away from it. This value is held into a single byte which is the two’s complement of the signal’s intensity in dB.

Computing the distance to a Beacon

When a scan response is detected by a device, it also determines the intensity of the received signal. Hence the iBeacon protocol uses the reference value held in the TX Power byte and compares it to the intensity of the signal effectively received. This allows iBeacons to compute an estimation of the distance to the emitting beacon. This is a great quality of iBeacons, but note that the intensity of the signal depends vastly on existing obstacles or simply on the geometry of the room. As a result Apple does not recommend to use iBeacons to determine precise locations.

The algorithm used to compute the distance is not open-source, although others have tried to emulate matching ones.

How to Use Apple’s SDK for iBeacon

Emitting or detecting iBeacon data is organized around iBeacon regions.

 

image01

These regions are instantiated with optional initial values such as the UUID, major or minor. In the case of detecting an iBeacon, this region object defines what type of beacon scan response should be detected. For example, if you provide a UUID, only the beacons with matching UUIDs will be detected, regardless of the major and minor. If you also provide these values, you’ll detect only beacons matching all three of these values.

When emitting an iBeacon signal, the region object based on the values of the UUID, major and minor generates the data structure to be advertised.

As you may have guessed, this makes the iOS SDK very simple to use! For more detailed examples, check out our beacon emitter and beacon detector tutorials.

However, it also makes things much more difficult when you are trying to use a protocol different from iBeacon! Let’s look into that immediately.

Using Apple’s SDK for AltBeacon or Estimote

We have seen how complicated the scan response can be, and how Apple simplified the SDK so that we just need to enter the UUID, major and minor to set it up. However, with other beacon protocols, the scan response has a different structure which Apple makes hard for us to tweak.

Detecting other beacons

When detecting iBeacons, the locationManager:didRangeBeacons:InRegion: method is called on the event of a detected signal. However, this is very specific to iBeacons. When detecting another BLE signal, you must not use a CLLocationManager instance, but a CBPeripheralManager which detects ANY BLE advertisement EXCEPT iBeacons, which will be blocked.

The callback that will be triggered upon detection is centralManager:didDiscoverPeripheral:advertisementData:RSSI: . The advertisement data that is returned is a dictionary holding 2 objects; one for each data structure of the scan response. Here is a sample response from an AltBeacon.

{
kCBAdvDataIsConnectable = 0;
kCBAdvDataManufacturerData = <1801beac 0cf052c2 97ca407c 84f8b62a ac4e9020 00090006 c5>;
}

The top element represents the first, three bytes long, “Flag” data structure. The second one represents the manufacturer specific data following the bytes describing the size and type of the data structure.

This is good news for us, and means we can detect any beacon information!

Emitting another beacon

We have found things are much trickier when it comes to advertising custom beacon scan responses. We can try to build an NSDictionnary similar to the one detected and try to advertise it using the startAdvertising method.

However the advertisement data keys available for detection are limited to only CBAdvertisementDataLocalNameKey and CBAdvertisementDataServiceUUIDsKey when it comes to advertising the data. It is Apple’s way of preventing us from building manufacturer specific data outside of the iBeacon protocol.

So there you have it! We went through apple’s iBeacon protocol, looked at how we could detect other beacons and apple’s restrictions to advertising data. We have some working examples and tutorials to build an iBeacon app on Swift – check out our beacon emitter and beacon detector tutorials, which allow you to get the best out of iBeacons by establishing a two-way communication which beacons aren’t usually capable of. The reason why we think it’s great is that we use PubNub to enhance beacons’ capabilities while still keeping their low energy consumption asset! Sweet, right?

Resources

Guest Authors 

Norvan Sahiner and Sunny Gleason wrote this tutorial series on behalf of PubNub, a platform that allows you to build and scale realtime apps for connected devices.

Facebook: A New Game for Beacons? | Guest Post

Facebook iBeaconThe adoption of iBeacon may have just been significantly changed by Facebook for their 745 million active mobile users, as reported on their January 28th SEC report.

As regular readers of this blog know, applications are required for iBeacon support within iOS devices and their hugely adopted app now supports GPS, WiFi and Bluetooth beacons for location data as a part of their “Foursquaresque” Pin Points feature rolling out in New York, the back yard of what made Foursquare a staple in 2007; albeit from manual user check-ins, something that Facebook also semi-automated in their app via GPS and WiFi rendering Foursquare obsolete in 2012.

A problem with this rollout is that most users have push notifications within the Facebook mobile application turned off. This fact is why the company separated their messenger application, so users had a new approval process within a unique application, to which Facebook hopes that its users will leave push notifications turned on.

They knew this data after their purchase of WhatsApp, an application that overwhelmingly has push notifications turned on, as it has built a trust relationship with users. To explain further, when you would “like” or “comment” and otherwise make small talk upon a Facebook wall, a notification would be sent to relevant users of the mobile application on a smartphone – interrupting their day with a non-critical message.

As Facebook has become a replacement for people’s off-hours or entertainment time, tapping into TV watching time as a way to socialize with remote friends, those alerts coming to phones were interruptive and broke the trust that users had with the application. Hence push notifications were turned off. Mark stated the reason for the two different apps was to pull up the message more quickly from the notification screen of iOS in this quote from 2014 “Whenever you receive a message through the Facebook Messenger app, it sends a notification to your phone so that you can quickly pull up that conversation.”

Most users keep push notifications for their SMS, WhatsApp, Telegram or other instant messaging clients turned on. But once an application gets “spammy” or otherwise interrupts your personal time with unnecessary alerts, it is either deleted or banished to the world of never alerting. Currently, if you turn alerts off in WhatsApp or the Facebook Messenger application, you are greeted with a dark screen stating “Please turn on Notifications” for the “app to work best” along with visuals on how to re-enable what they deem optimal to you. They designed it to mimic an error message to entice users to turn the functionality back on.

With the current Apple iOS security model, in order for iBeacon to automate an app, notifications along with Location Based Services settings must be both turned on.   Therefore this rollout of iBeacon support in Facebook proper app will not be useful in having a user launch an application within a space. That being said, once they launch the app to front, it will be able to read any beacons present and automatically display tips, coupons or other content in their database for that position. It was nice to see they are also using WiFi and GPS for this, as the beacon rollout worldwide is negligible at this time. This is why my company NewAer focused on any radio signal that sends out a beacon, long before iBeacon was announced.

Google has the potential to go big with users as well. Scott Jenson is working on a Google project that enables “seeing” beacons within mobile Chrome on Android, along with a URL string that is buried within the Meta data of a beacon broadcast framework. I liken this to a QR code as they embedded direct URLs, but beacons could have a potential spammy element.

Take this scenario; as you walk by a Zip Car; whether you are a subscriber to the car sharing service or not, your Chrome browser would ask you if you wish to head to the Zipcar.com website to reserve a car or learn more about the service. Think of it as a digital dousing rod on your path through life with the potential for more “heads down” behavior into your smartphone.

The story remains to be told on whether Apple relaxes its security practices around the way apps are woken up by beacons, how many beacons an application can support, or whether Facebook moves iBeacon support into the Messenger application which has more users with “push notifications” turned on. It’s still to early to say whether the Google or similar Samsung approach of a browser or client at the mobile operating system level will be the winner in consumer eyes for proximity based marketing, engagement or other automation.

Either way, we’re excited to see Facebook in the game of bringing contextual relevance to the masses. Lets just never let this become spam 2.0, OK?

Guest Author: Dave Mathews

Dave Mathews is founder and CEO of NewAer, the first proximity platform software that runs on Android, iOS, OSX and Windows enabling peer to peer discovery of devices on any supported radio as well as unpaired messaging between clients. More on his software as a beacon engine can be found at proximityplatform.com online. Dave is an expert in the machine-readable code space since his 1997 invention the CueCat, the first PC based Internet of Things (IoT) device. This PS/2 or USB tethered reader took any printed barcode and delivered users to specific websites automatically based upon their physical location, years before Location Based Services (LBS) and QR codes attempted the same for mobile phones.