Apple has had a string of promising technologies lately that have been slow to get real-world takeup. CarPlay, announced in 2012 as iOS in the Car, is only this year seriously showing up in cars' infotainment systems. Handoff, which debuted in 2014, has gained very little third-party developer adoption and has seen little use even by Apple outside of handling texts and calls across devices. Maybe Microsoft's new take on Handoff will fare better.
Then there's the iBeacons protocol that lets a smartphone app get local information on demand by reading the ID of devices called beacons. Each beacon has a unique ID, which an app maps to a database that tells it the beacon's location or other information specific to it.
iBeacons was supposed to revolutionize retailing, by letting customers get more product details and order the displayed items in their sizes or preferences, as well as allowing retailers to track and engage with customers as they moved about a store. Beacons' uses transcend retail, of course -- beacons could also provide info on museum artifacts, transit options, where vegetables in a store bin were grown, and so on when engaging the real world.
Apple didn't invent beacons, but its iBeacons protocol opened up a common technology that app developers and those deploying beacons could use. Before iBeacons, a particular vendor's beacons worked with only that vendor's software. With iBeacons, manufacturers quickly adopted the Apple standard, even if they also offered their own "enhanced" protocol.
Retail is where the action -- and money -- was supposed to be for beacons. But it's not.
Deploying a few beacons is easy, deploying many beacons is hard
Beacons vendors have struggled to gain adoption. That's partly because beacons are hard to deploy. Managing a standard beacon, whether to replace their batteries or to do security updates, is a manual affair that requires someone go to each beacon in person and use a Bluetooth connection for each update.
The methods that various beacons vendors have used to get around that highly manual management -- including the use of hard-wired Wi-Fi units and various mesh networking technologies -- are costly and complex to implement.
You can spend big money on human labor to manage beacons, or you can spend big money installing devices and running management software whose complexity is akin to that of a network or manufacturing management system.
That makes beacons a very expensive proposition to consider -- and ultimately, for what benefit? Store maps, kiosks, and in some cases GPS geolocation within a smartphone can provide the location information on which beacons' services depend.
Plus, retailers have seen a much simpler technology that can provide similar location data to get relevant information -- QR codes -- come and go quickly. Remember when they were everywhere? Then they were gone.
Beacons are basically expensive programmable QR codes with batteries. The investment is too high for what could be a low-value fad.
A big hurdle for customers to adopt
After all, a beacon does nothing unless the customer has a compatible device, and the iBeacons technology does nothing unless the customer has an iPhone, is running the retailer's app, and has enabled iBeacons for it. Getting people to adopt such apps at scale is hard.
On the plus side, it tends to be the most loyal shoppers who would do so, and they tend to spend a lot. On the other hand, they know the stores and probably don't need beacons' assistance in the first place.
Ironically, Apple's commitment to user privacy means that retailers making the investment won't get much data from people with iPhones.
Apple faced the same resistance with Apple Pay, since retailers wanted customer data that Apple refused to provide. But the failure of the retailers' own CurrectC technology, coupled with the poor rollout of chip cards in the United States, overcame that -- chip cards are so slow that retailers have often chosen to keep using insecure swipes or to finally adopt Apple Pay even without that access to that user data. Because it's fast and easy, the checkout lines keep moving. But I don't see an equivalent outside force that would overcome iBeacons resistance.
The Eddystone factor isn't much of a factor
Google has a competing beacons protocol for Android called Eddystone that doesn't require users to have a compatible app for the store they're in. (Eddystone also works with iOS apps.)
Eddystone can run on Android as a system service, in a sort of broadcast mode, so Eddystone-compatible beacons can be used to track any Android user. (Google needs to invade your privacy to make its money, let's not forget.) A new extension to Eddystone allows for some data privacy, such as for apps that track your key fobs or other individual assets.
In the United States, only half of the smartphone-carrying populace uses Android, and iOS users tend to be richer, so retailers who want to use beacons can't simply ignore iBeacons in favor of Eddystone. The car makers have seen what happens when you offer one broadly available platform technology but not the other (Android Auto, but not CarPlay, in this case): Customers get very upset and don't buy.
Instead, it's becoming clear that retailers are ignoring the beacons notion altogether. Maybe that'll change if Apple and its partners can figure out how to ease beacons deployments and management or if retailers discover a valuable new benefit that they can't otherwise get.
Don't hold your breath.