There are two ways to approach deploying iBeacon. You can either build a siloed experience (your beacons in your venue interacting with your app) or you can open that network to others, sharing to other apps. In the latter scenario, you maintain the venue and beacons themselves while third parties can lease access to that beacon network to deliver content, which can vary from indoor navigation to real-time contextual advertising.

Open beacon networks will be especially useful in huge locations with a lot of foot traffic generated by diverse group of people. Think airports, shopping malls, or smart cities. And as many projects involving beacons move from pilot stage to major deployment throughout 2015, we will be seeing massive interest in this approach. That’s why today we’re introducing an update to Estimote Cloud: infrastructure sharing. It’s a new feature that enables allowing third party apps access to your beacons in an easy and secure way.

Building the network

Imagine a big airport, that has beacons deployed at every gate and throughout the concourse. Even if you’re a frequent traveler, the chances are slim that you have an app installed for every major airport out there. It’s much more likely that you have the official app of your airline of choice. Let’s call it Air Lemon. Since Air Lemon doesn’t own the airport facilities or the physical venue itself, it’s not in a position to deploy beacons, even though that contextual information would makes its mobile experience far better. Instead, the airport will invest in a beacon network, similar to a wifi network that it opens up as a public utility to both its partner airlines and their passengers. With Estimote Cloud’s infrastructure sharing, the airport can now grant Air Lemon access to a subset of its beacons, making that app smarter and better. For instance, giving it the ability to guide you to the right gate at the exact right moment.

The airport might also be sharing its beacons with Air Blue. Let’s say that instead of indoor navigation, their app automatically pulls out your boarding pass when you approach the gate. That’s why Air Blue only needs access to beacons installed near the gates they’re using. With Estimote Cloud’s infrastructure sharing, this can be managed with just a few clicks. The airport has the flexibility to choose any number of beacons and share them with as many partners as they’d like. Any space can be divided into sections owned by particular apps, or conversely, have all deployed beacons accessible for every collaborating publisher. The sharing configuration is completely flexible.

This creates an enormous number of possibilities. Scavenger hunts, in-store analytics or personalized dynamic pricing are possible mobile applications built on top of beacon networks. It will be fascinating to see how infrastructure sharing accelerates contextual computing in the months and years ahead. What in the past was possible only in the browser can now be achieved in the physical world as well. This means opening up new revenue streams and business models both in mobile and brick-and-mortar spaces. Some of them, like the airport example or a shopping mall with a real-time ad exchange, are obvious. But we’d love to see developers implement this feature in ways we haven’t yet thought of, just like we didn’t expect many of the use cases behind some of the most successful startups leveraging iBeacon. Because the truly amazing thing about building a new technology is seeing how it evolves in the hands of its users.

Cloud is key

Security lays at the foundation of infrastructure sharing. We have written a lot about this previously, and last Fall we released a massive update to all core elements of our platform. It included a security mechanism called Secure UUID that uses Estimote Cloud to encrypt the IDs of your beacons. Secure UUID makes it impossible to piggyback on them. Infrastructure sharing is built on top of this technology. Thanks to that, you can rest assured that only authorized people can see the true UUID, Major, and Minor values of your beacons.

If you want to share beacons, first you need to enable Secure UUID on them (in case you don’t know how to that, we’ve explained it elsewhere). Then simply select the beacons in the Estimote Cloud dashboard and click Share Beacons. All you need to do now is provide the App ID of the application that you want to invite (this article has you covered on that). The owner of this app will see those beacons in the Apps section of Estimote Cloud. Now this app also has the key to resolve Secure UUID. Remember that people you share beacons with will not be granted anything beyond read-only access to the IDs of beacons you selected to lease. They won’t be able to change, or even see any of the settings. Everything stays under your control, and you can also revoke permissions at any time.

After the growth we’ve seen last year, both at Estimote and around the entire iBeacon space, we have no doubt that beacons will be everywhere. And it will be more engaging if more than one app can take an advantage of a beaconified space. Right now there are more than 40,000 mobile developers in our community, building amazing mobile experiences. Now they can run their apps on existing infrastructure, in retail and beyond. We believe it will accelerate mobile innovation and user adoption inside these spaces and create unique monetization opportunities for beacon app developers who collaborate with brands and retailers.

This is just the first release of our infrastructure sharing feature. It’s an extremely important component of Estimote Cloud and in the next couple of months you will see us investing a lot of resources into expanding this technology. In the future we want to add in-depth analytics, even easier integration with Estimote SDK, and of course support for Estimote Stickers, so that the developers of tomorrow will be able to feed their apps not only with micro-location, but also product-level context. But since today is just the first release of this feature, your feedback is crucial: don’t hesitate to tell us how you like it and what aspects we should prioritize. We need your help in shaping the future of beacon networks, so let us know what you think via email and on Twitter, and don’t forget to read more about infrastructure sharing on Estimote Community Portal!

Apple Watch’s debut is just around the corner but WatchKit, Apple’s framework for building Watch extensions for iPhone apps, has already been out for quite some time. We know that thousands of you have been eagerly waiting to start working on integrating iBeacon and nearables with the most exciting wearable of the season. So here it is: Estimote WatchKit SDK, consisting of an open-source demo app and a beta build of Estimote SDK 3.0, which includes tools to smoothen the Watch app ⇔ iOS app communication, and Nearables Simulator to go along with the Apple Watch simulator already available in Xcode.

How to build your first WatchKit app with stickers?

A quick recap on the architecture of the WatchKit app. We have the WatchKit app itself, it runs on the Watch and it’s only about the presentation layer. We have the WatchKit extension which resides on the phone and runs all the Watch-related code. This code is supposed to be lightweight, so it’s not a good candidate for beacon/stickers ranging and monitoring. And finally, we have the “parent” iOS app, also running on the phone, in a separate process — and that’s our perfect spot for any long-running, background tasks like monitoring.

There’s the catch: the WatchKit extension and the “parent” app live in separate processes and sandboxes, so if we’re to pass beacons or stickers ranging/monitoring results from the app into the extension, we need to employ some inter-process communication. Apple has naturally given developers all the necessary tools to do it, but at Estimote we went one step further to make sure that you can have your beacon-enabled Watch application up and running in no time. So let’s talk about ESTNotificationTransporter, the latest addition to the 3.0 beta of the Estimote SDK. Shameless plug: there’s a lot of other changes coming in 3.0, and since it’s still in the beta phase, we would love to hear your feedback about it.

The way you’d usually go about communicating beacon and stickers ranging results from the iOS app to the WatchKit extension:

1. [iOS app] Receive the ranging results in your didRange delegate.
2. [iOS app] Serialize them and put them into a “shared storage” — the App Group.
3. [iOS app] Notify the WatchKit extension that new ranging results are available.
4. [WatchKit extension] Receive the notification from the iOS app.
5. [WatchKit extension] Read and unserialize data from the App Group storage.
6. [WatchKit extension] Act on the newest data.

ESTNotificationTransporter takes care of all of that for you.

First, in your Project Settings, on the Capabilities tab, enable the App Group capability and add an App Group, e.g. group.com.example.helloWatch. In both your iOS app and WatchKit extension’s code, obtain an instance of the ESTNotificationTransporter and set it up with this App Group identifier:

self.transporter = [ESTNotificationTransporter sharedTransporter];
[self.transporter setAppGroupIdentifier:@"group.com.example.helloWatch"];

Then, set your iOS app with beacon or nearable manager as usual — let’s assume it’s the nearable manager. In the didRangeNearable delegate add:

- (void)nearableManager:(ESTNearableManager *)manager 
       didRangeNearable:(ESTNearable *)nearable {
    [self.transporter saveNearable:nearable];
}

In your WatchKit extension’s setup, subscribe to appropriate notification:

[self.transporter addObserver:self
                     selector:@selector(didRangeNearableViaNotification:)
              forNotification:ESTNotificationDidSaveNearable];

…and add the code to handle it:

- (void)didRangeNearableViaNotification:(NSNotification *)notification {
    ESTNearable *nearable = [self.transporter readNearable];
    // TODO: add your Watch app response to the ranging results here
}

That’s it for ranging nearables, but the ESTNotificationTransporter can also handle communication around enter and exit events, proximity zone changes etc. Well, let’s go through one more example then — enter the range of a nearable. In the didEnterIdentifierRegion delegate add:

-  (void)nearableManager:(ESTNearableManager *)manager 
didEnterIdentifierRegion:(NSString *)identifier {
    [self.transporter notifyDidEnterIdentifierRegion:identifier];
}

In the WatchKit extension’s setup:

[self.transporter addObserver:self
                     selector:@selector(didEnterNearableRange)
              forNotification:ESTNotificationDidNearableEnterRegion];

And the handler method:

- (void)didEnterNearableRange {
    NSString *id = [self.transporter readIdentifierForMonitoringEvents];
}

We’ve prepared an example Sneaker Seeker app which illustrates the whole concept. It’s very similar to the Proximity Demo from the regular Estimote SDK, so those of you familiar with it should already know the drill. It uses ranging to approximate the distance from an Estimote Sticker, and determines in which proximity zone the user is. As the user moves between zones, the Watch app reacts accordingly, updating content in real time. Sneaker Seeker is part of the Estimote WatchKit SDK, so feel free to check it out today.

Nearables simulator

You know how to code up the communication between the app that’s on your iPhone and scanning for beacons or stickers, and its WatchKit extension. The question is: how do you go about testing it? You can only run your Watch app in a simulator at this time, and the simulator doesn’t exactly work with beacons or stickers…

You could mock it all up, but it’s time consuming, so… we’ve done it for you! Meet another addition to the Estimote SDK 3.0 — ESTSimulatedNearableManager:

self.simulator = [[ESTSimulatedNearableManager alloc]
                  initWithDelegate:self
                  identifier:@"0a1b2c3d4e5f6a7b"
                  zone:ESTNearableZoneFar];

This instantiates the simulator with a single, simulated nearable with the specified ID and in “far” distance to the phone. While at this time proximity zone is the only property that’s being stubbed out by the simulator, we’ll be adding more of them soon, so that you can also simulate your nearables moving, flipping around, getting cold etc. These leverage our built-in accelerometer and temperature sensors, which give incredible context to objects!

The simulator works just like a regular ESTNearableManager, so we can now start ranging for our simulated nearable:

[self.simulator startRangingForIdentifier:@"0a1b2c3d4e5f6a7b"];

…and receive appropriate events (didRange, didEnter, didExit) to our ESTNearableManagerDelegate like usual — only it will actually work in the iOS simulator, providing a “virtual” ESTNearable object:

- (void)nearableManager:(ESTNearableManager *)manager
       didRangeNearable:(ESTNearable *)nearable {
    // assert(nearable.identifier == @"0a1b2c3d4e5f6a7b");
    // assert(nearable.zone == ESTNearableZoneFar);
    // ...
}

Naturally, the simulator wouldn’t be much useful if we couldn’t dynamically control the properties of the simulated nearable and trigger enters or exits on demand:

[self.simulator simulateZoneForNearable:ESTNearableZoneNear];

Monitoring works, too!

[self.simulator startMonitoringForIdentifier:self.nearable.identifier];

.

[self.simulator simulateDidEnterRegionForNearable:self.nearable];

...

-  (void)nearableManager:(ESTNearableManager *)manager
didEnterIdentifierRegion:(NSString *)identifier {
    // assert(identifier == self.nearable.identifier);
    // ...
}

.

[self.simulator simulateDidExitRegionForNearable:self.nearable];

...

- (void)nearableManager:(ESTNearableManager *)manager   
didExitIdentifierRegion:(NSString *)identifier {
    // assert(identifier == self.nearable.identifier);
    // ...
}

Finally, once you’re past the development and testing stages, and ready to go live, all it takes is to replace the ESTSimulatedNearableManager with a regular ESTNearableManager. You’ll also need to remove any simulator-only methods from your code.

Coming soon: more Apple Watch goodies

We’re just getting started with Apple Watch support. Expect additional examples joining the Sneaker Seeker app soon, to demonstrate how beacons and stickers can interact with glances, notifications and more. We’ll be also adding an ESTSimulatedBeaconManager, and expanding the capabilities of the nearables simulator. And because we’re so excited about how wearables and nearables will work together, in the coming weeks you’ll see a lot of content related to this subject on our blog, Community Portal, and in other places — tutorials, inspirations, anything to help you build the “killer app” for Apple Watch.

Now it’s time for you to let us know how you like the new update, and what cool ideas for context-aware applications you can think of in regard to wearables. We’ve just recently opened new Estimote Community forums, so it’s a great place to start the discussion on beacons, nearables and Apple Watch. You can of course also reach us on Twitter and in the old fashioned way.

Piotr Krawiec, Technology Evangelist at Estimote
Wojtek Borowicz, Community Evangelist at Estimote

2015 is already off to a great start at Estimote HQ. More and more companies are using our beacons to grow their businesses, we’re shipping stickers, and our SDK is updated with Apple Watch support. While most of this growth is made possible by our over 40,000 strong native mobile community, we believe it’s just as important to build for a whole spectrum of developers. Today, we’re happy to announce Estimote SDK support for C# and Javascript along with our partners Xamarin and Evothings.

Xamarin and C#

The Xamarin Platform enables developers to create native iOS, Android, and Windows apps in C# and share code across all platforms. With 950,000 active developers in the ecosystem, it’s no surprise that C# developers have been building with Estimote from the beginning. Over the past year, we’ve been working directly with Xamarin to create a binding for the Estimote SDK–you might have seen the first stages of this collaboration a few months ago. Now, a new component is available. The latest Xamarin binding supports the newest stable version of the SDK (2.4), which includes integration with Estimote Stickers and our brand new trigger engine.

The Xamarin component for Estimote gives you access to features that until now were only available for Objective-C and Swift developers. The coolest addition is full support for stickers. You can now detect stickers and perform monitoring and ranging based on ID or sticker type (monitor for fridge, dog, or bag stickers etc). The binding opens up our trigger engine (one of the most powerful elements of our SDK), allowing you to include additional logic into your app, based on motion, orientation, temperature and time sensor data. Changing beacon settings and turning on Secure UUID can also be done using Estimote Cloud. Last but not least, the binding supports C# features including events and async/await support.

Are you ready to build apps using C# and Estimote SDK? Good! You can download the component and read a great introduction on the Xamarin blog.

Evothings and JavaScript

Web developers also love beacons. And Estimote loves developers who love beacons, so we’re excited about the work Swedish startup Evothings is doing. They are on a mission to make it easy to build Internet of Things projects with JavaScript and HTML5. Since rolling out support for Estimote Beacons in 2014, they’ve now released an update to include nearables and Estimote Cloud integration as well.

Similar to Xamarin, Evothings’ JavaScript API lets you monitor and range for stickers, as well as leverage trigger mechanics to elevate your apps with more context. Most importantly, the API is built into their core product: the Evothings Studio. It allows developers to see changes instantly because the app automatically reloads on all connected devices as soon as a file is saved. Support for nearables is implemented as a Cordova/PhoneGap plugin. It’s open source and can be used to build a native app ready for publication on the App Store. The plugin also supports Estimote Beacons.

Estimote Nearables are a completely fresh take on beacon technology. The potential areas of use of nearables surpass those of basic iBeacon by far. We are proud to make nearables available to JavaScript developers and are excited to do this together in partnership with Estimote. - Mikael Kindborg, Lead Architect at Evothings.

Grab the Evothings Studio Starter Kit for nearables and start coding!

The best is yet to come

We promised you in January that we’re focused on bringing beacons and nearables to all types of developers and programming languages. We want to expand into new platforms and technologies so that every programmer can build their own contextually aware apps. Let us know how we can support you as you build with these new programming tools. Don’t hesitate to drop us a line, tweet @Estimote, and start a discussion on our new Community Forums!

Wojtek Borowicz, Community Evangelist at Estimote

Time flies: iBeacon will soon turn two, and shortly thereafter it’ll also be the Estimote SDK’s second anniversary! And what an intense time it’s been for our SDK. We started with a thin wrapper on top of Core Location and then added beacon configuration, Estimote Cloud, Secure UUID, analytics, stickers support, Trigger engine, and infrastructure sharing … and we’re just getting started! We’ve got lots of cool and useful features in the pipeline, all designed to move beacon technology forward, making it more powerful and accessible to developers — but we also recognize that all of this comes at the expense of increasing the complexity of the tools we’re providing.

Designing a clear, intuitive API for an increasingly complex SDK is a great challenge, but it’s one we’re excited to tackle. That’s why we have taken all the lessons we have learned so far, combined them with the amazing feedback we have heard from our ever-growing community of developers, and devised a revamped API that’s not only easier to use and understand but also a solid foundation for all the upcoming extensions on our roadmap. We’ve spent hours at the whiteboard, consumed dozens of our favorite vegan energy bars, shuffled things around, renamed a few others, brainstormed and brainstormed some more, and … here it is: Estimote iOS SDK 3.0.

What’s changed, why, and what’s in it for you? Read on to find out!

Did somebody say “separation of concerns”?

When building a beacon-enabled app, there are always two distinct areas that require your engineering attention.

First comes your application’s “beacon logic.” How do you want the app to interact with beacons? A simple geofence? Differentiation based on proximity zones? Do you need it to work in the foreground or in the background? What other business logic comes to play, e.g., new versus returning customers, current special offers, the weather outside?

Naturally, all of that isn’t of much use without beacons themselves — configured properly at that. Which is where the second point kicks in: beacon management. We’ve made it much easier with the introduction of Fleet Management, but sometimes it still makes sense to build your own tools. Maybe you need the beacons automatically registered in your own backend. Or you want to dynamically (and completely programmatically) figure out the optimal settings for a beacon, e.g., based on the size of the room the beacon goes into. Or you’re distributing the beacons to your own customers and want your app to handle the configuration for them.

The two areas play an equally important role in building a successful beacon-powered app, yet they rarely intersect on the code level. An automated beacon-configurator feature that you’re building as part of your app most probably won’t use geofencing. And vice-versa, the geofence that makes notifications spring up rarely (never?) needs to connect to the beacon and update its configuration. Yet to date, we had a single ESTBeacon class that tried to be in the middle of all of this action.

ESTBeaconConnection springs to life

We moved out all the management and connection-related methods and properties into ESTBeaconConnection and ESTBeaconConnectionDelegate classes. Connecting to a beacon is still an asynchronous process, so the flow remains similar: start the connection process, wait until the beaconConnectionDidSucceed gets called (remember to implement a beaconConnection:didFailWithError: too), and … voilà! You can now read the connection-only properties of a beacon, and start writing new settings.

But wait, that’s not all.

ESTBeacon is no more (and neither is ESTBeaconRegion)

So check this out. With most of the properties and configuration methods specific to Estimote Beacons now living in the ESTBeaconConnection, we decided it only makes sense for the beacon managers to start returning plain CLBeacon classes when ranging beacons. This should make migrating from Core Location to the Estimote SDK (to benefit from things like Fleet Management, Secure UUID, Analytics or Infrastructure Sharing) much easier. If you have any methods or 3rd party libraries that operate on CLBeacon objects, they’ll continue working just fine after the migration.

And while we’re at it… We replaced ESTBeaconRegion with CLBeaconRegion too! Unlike the ESTBeacon, ESTBeaconRegion was always directly inherited from its Core Location counterpart, adding very little on top of it. Reverting to a plain CLBeaconRegion means even more interoperability with the existing, Core Location-dependent code and libraries.

There were however two things ESTBeaconRegion had that CLBeaconRegion doesn’t.

First: the inMotion flag, which you could use to narrow down the region to beacons in motion only, thanks to the Estimote Motion UUID feature. Since the whole idea really is about broadcasting a different UUID when the beacon is in motion, we now enable you to access it directly with the motionProximityUUIDForProximityUUID: class method of the ESTBeaconManager.

And then, there was the “secured” parameter in the initializers, used when you wanted to range and monitor for Secure UUID beacon regions instead of regular ones. Which brings us to…

One manager, two managers, new managers!

After we dealt with the complexity of ESTBeacon, it left us with the ESTBeaconManager that took the now-vacated throne of the “one class to do it all” kingdom. It’s a wrapper on top of the Core Location’s CLLocationManager, adding a bunch of supplementary features (like avoidUnknownStateBeacons), it fetches beacon data from the Cloud, it also does Core Bluetooth beacon discovery, and on top of that handles the complexities of scanning for Secure UUID beacon.

No, it doesn’t make coffee (sadly).

Well, we now have dedicated managers to do all that. ESTBeaconManager remains a variation on the CLLocationManager, supercharged with the same extra features the old one used to have. Secure UUID beacons? Pass the same CLBeaconRegion to the ESTSecureBeaconManager instead, and receive your callbacks in the same ESTBeaconManagerDelegate.

Core Bluetooth-based discovery lives on in the ESTUtilityManager, and returns ESTBluetoothBeacon objects through the ESTUtilityManagerDelegate.

Fetching beacon data from the Cloud is now a responsibility of the ESTCloudManager, for both beacons and nearables.

And of course, we still have the ESTNearableManager and the ESTTriggerManager.

Last but not least: if you’ve seen our Estimote WatchKit SDK, you already know we’ve introduced special “simulator” manager to let you test your nearables apps in the iOS simulator — i.e., if you’re preparing for the imminent release of the Apple Watch. Meet ESTSimulatedNearableManager, reporting back to your regular ESTNearableManagerDelegate, only with simulated beacon and nearables events. ESTSimulatedBeaconManager will be joining the club soon!

We’re also thinking about adding a high level wrapper on top of three of the new managers: the ESTBeaconManager, the ESTSecureBeaconManager and ESTSimulatedBeaconManager — a wrapper that’ll automatically re-route your ranging and monitoring requests to the proper manager, based on whether you’re running in a simulator and whether your beacons have Secure UUID enabled. Would you like to see something like this? Let us know!

Firmware 3.0

Today we’re not only releasing SDK 3.0, but also beacon firmware 3.0, which brings a new feature we call “conditional broadcasting” to Estimote Beacons. Conditional broadcasting consists of two new modes of operation that you can enable on your beacons:

• Flip to Sleep: turn the beacon upside down (i.e., with the adhesive layer facing toward the ceiling) and it will stop broadcasting. This is a really useful feature to turn the beacon “off” and simulate enter / exit region events in your app. It’s also quite helpful when working with large number of beacons in a single space.

“Flip to Sleep” is also coming to the Estimote iOS app in the next update.

• Motion only: with this mode enabled, the beacon will only advertise when it is in motion. This greatly saves battery life for those use cases that can take advantage of it! Not to be confused with Motion UUID feature, which makes the beacon advertise a different UUID when in motion — but will still advertise its regular UUID when stationary, so no battery savings there.

Notably, firmware 3.0 also brings some changes to the beacon authorization procedure, making this update backward incompatible (hence the major version bump). This means you’ll only be able to connect to and change settings of “3.0 beacons” using Estimote iOS SDK 3.0 and Estimote iOS app 2.12 (pending App Store approval now, will be available very soon). Older SDKs and apps, as well the the Android SDK and Estimote Android app will still be able to detect beacons, but won’t be able to change their settings.

That’s all, folks!

We’ve updated all of our examples and API documentation to reflect all the changes, so if you’re still not sure how to update your beacons’ firmware in the SDK 3.0 era, or how to use Motion UUID now, head over there. You can (should!) also take a look at the handy SDK 2.0 → 3.0 migration guide we’ve prepared to make the transition as smooth as possible.

We’ll be focusing all our development efforts on the SDK 3.0 from now on, with SDK 2.0 still receiving critical bug and security fixes for some time. We’ll naturally give you ample heads-up before we decide to stop supporting it at all, but we recommend upgrading to the new tools as soon as possible. Because why wait, if you can have all the cool new features right now?

That’s it for the SDK 3.0 announcement! Love it, hate it? Let us know on Twitter, our still-fresh-from-the-oven, brand-new Community Forums, or simply drop us an email at contact@estimote.com.

Piotr Krawiec, Technology Evangelist at Estimote
& the Estimote SDK team

Today we’re excited to announce a really powerful evolution to the Estimote Platform that we launched last fall: a brand new API that allows you to integrate the remote management capabilities of Estimote Cloud into any of your own apps and back-ends. In other words, managing beacon networks at scale just became incredibly elegant and seamless. This API is available today in private beta (more details below) and will transition to fully open soon.

Before we go into the technical details, some quick thoughts on the strategy and thinking behind how we approach product development.

Building a developer-centric platform

When we set out to build Estimote over two years ago, our goal was to be a true technology platform for beacons. In following this strategy, we stay close to a few guiding principles. First and foremost, every product and business decision we make must be uncompromisingly focused on delivering value to people who build products. Sometimes people interpret that to mean our products are only good for developers who spend time on side projects and “hacks.” In reality, we optimize for the creator (40,000 and counting), whether that be a mobile engineer working at a Fortune 100 company building beacons in to the next major release, or a startup founder thinking up the next killer app that will touch millions of consumers. Regardless of what they are dreaming up, developers simply need software and tools that make their lives easier—systems that are flexible, extensible and scalable.

Second, we don’t try to be one-size-fits-all. Smart engineers don’t want a “solution” forced upon them. In other words, when building a platform, knowing what not to build is just as important as what we do put on our roadmap. It’s one of the reasons we don’t focus too much on a content management system (CMS) tied to beacons. We sell beacons worldwide to engineers in diverse industries (retail, transportation, health care, nuclear, and even outer space!). We recognize we could never provide a turnkey solution suited to the diverse needs of all those verticals. Instead, developers specializing in their areas of passion should have the tools and freedom to build on top of Estimote’s infrastructure, using rich web services to do so. We really admire best-in-breed companies who have built platforms with this approach, from Stripe to Twilio to Docker. 

That last point dovetails nicely with our third principle: the only way Estimote can make money is if others are able to build value in adjacent areas of the stack. The hardware and software we build should encourage other companies to derive more value from their own products and services—whether a Big Company mobile PM in New York, an agency designer in London, or a Japanese startup ninja. If we provide the right mix of solid products and exceptional support which extends elegantly from lab prototyping through to full-scale rollout, many companies will prosper together.

Managing a beacon network at scale

As iBeacon rapidly matures and larger networks are deployed, we’re constantly working on solving new challenges that emerge at scale. Whether that’s speeding up development, hardening security or readying beacons for Apple’s latest platform, we work to anticipate roadblocks and eliminate them before you get stuck.

A common question we get is how does the infrastructure work when beacons are deployed across thousands of remote locations. What happens when you need to update settings, check on battery life, etc.? In recent months, we’ve pushed a series of updates to Estimote Cloud and the Estimote iOS App that provide easy and efficient ways to do all of that. 

And now we are extending the Estimote Fleet Management API to allow you to programmatically configure updates to your beacons’ settings from within your own code, including from back end tools of your choice. It’s effectively the same functionality as what you can do today from our Cloud Dashboard. All of your beacons will get updated as soon as you enter range if the Estimote iOS App is installed on your smartphone.

Integration with Estimote SDK 3.0

But again, the real power is in APIs that extend to your platform. That’s why we made the Fleet Management API work with our brand new 3.0 SDK. We added a set of new methods that allow you to embed this functionality directly into your own iOS app. Managing your beacon fleet is now totally scalable, using your distributed app as the proxy to seamlessly reconfigure deployed beacons. The update functionality even works in true background mode, meaning as soon as a beacon is within range of a phone with your app installed, staged updates will propagate through your entire beacon network. 

We’re big fans of this approach to at-scale fleet management, particularly because it requires no additional hardware, specialized technicians, or expensive overhead. It’s fast, scalable and seamless. This new API is available as a private beta today. For access, please email Tanuj on our Business Team.

Calling all beacon CMS’s

We love that tons of “Beacon CMS’s” have popped up around the world, specializing in diverse industries and catering to a variety of domain-specific needs. Many of these CMS companies already integrate with Estimote and the Fleet Management API will make those integrations even more powerful. If you’re building a beacon CMS, this API lets you focus on your part of the value chain while Estimote powers the underlying beacon infrastructure for you and the end customer.

This modular approach makes your beacon CMS product much more robust. Now your customers can not only manage content, but also the network itself. Take a company like Rover, one of the most elegant CMS’s in the beacon space today. Now their customers can not only manage all their marketing campaigns and analytics, but will soon be able to also monitor and update their beacon network distributed across thousands of stores—all from one central dashboard.

At Estimote we deeply believe that platforms are only as good as how extensible they remain in to the future. The reality is it takes unbelievable engineering and a vision to move a platform forward while at the same time making sure things don’t break. And this is precisely why beacon infrastructure is not an interchangeable commodity. We’re super excited to power a whole new generation of applications with beacons and are committed to working hard to create the developer-facing tools to do so. 

Thoughts, questions, concerns?

As always, we’re here to answer questions, listen to feedback and discuss anything and everything beacons. Please reach out any time and stay tuned for more feature updates in the weeks ahead. Feel free to drop us a line and ping us on Twitter anytime!

Tanuj Parikh, Head of Business at Estimote

Arek Flinik, Senior Software Developer at Estimote

“Design is a dialogue between designers and users” - Emmet Connolly

At Estimote, we’re firm believers in wearables. It’s why we released our WatchKit SDK (for building location-aware apps for the Apple Watch) weeks before the watch itself was available. We believe wearables are the next frontier for contextual computing. Location awareness is steadily gaining traction on mobile, but it’s this next step that will turn context from a ‘nice to have’ to an indispensable part of the user interface.

The evolution of mobile devices–from large screens we take out of our pockets to much smaller screens strapped to our wrists–will change how we experience the world around us. Beacons add another dimension to this evolution, similar to the incredible wave that smart technologies like Android Wear are creating. To better understand the potential of wearables, we sat down with Emmet Connolly, a co-founder of Google’s Android Wear initiative and currently Director of Product Design at Intercom. We discussed all things contextual computing and the future of wearables, nearables and the potential synergy between them. Enjoy the read!

Wojtek Borowicz, Community Evangelist at Estimote: Android Wear has been out for quite some time already, and Apple Watch is about to hit the shelves. How do you expect the next year or two to look for wearables?

Emmet Connolly, Director of Product Design at Intercom: I think they’re going to be really interesting! We’ve had all these open questions for a while now, and I expect a lot of the answers start to become clearer.

How mainstream are these devices going to become? How will they materially improve the lives of ordinary people? How will designers overcome some of the inherent challenges like limited input and social acceptability? Design is really a dialogue between designers and users, and now with significant adoption starting to happen we’re finally going to be able to get some answers.

WB:Smart watches seem all the rage now. Are there any other wearable form factors you think might take off in the future?

EC: There’s a reason it’s not called “Android Watch”! There are many different ways of slicing the problem. So yes, I absolutely expect different form factors to happen. I thought that the Runcible was pretty interesting, for example. Odd and totally niche, but fun and different and suggestive of a bunch of other things.

In some ways I feel like we’re in the “horseless carriage” phase of wearables, with a lot of really literal references to traditional watches. I’m not even all that attached to the “wearables” label at all. It seems unnecessarily limiting. There are so many different ways of making a computer that make sense.

For example, we don’t just have one type of motor vehicle, right? We have cars, motorbikes, trucks, vans, bulldozers, tractors, buses, and so on. The combustion engine led to lots of different vehicles that are suitable for different needs. And I think it’s going to be the same for computers. We won’t just have the computers, we’ll have desktops, laptops, tablets, phones, TVs, watches, bracelets, rings, clothes, pocketables, magnets, pendants and who knows what else. But each will be best suited to a particular task or context.

WB:Where do you expect wearables to make the biggest impact? Payments, communication, fitness apps… or maybe something completely different?

EC: My short answer is diagnostic health: there’s a huge opportunity there to make these devices indispensable to how we live. To make them so important and valuable that you can’t not have one. I think we’ll look back on how we diagnose our health problems today and be quite horrified at how ridiculously antiquated it all was. It just seems so random and scattershot and reactive.

But there are huge challenges at a technical level to get all of the sensors working reliably and especially at a regulatory level because the cost of giving bad health advice can be fatal. That’s why so many of the fitness type devices seem to be languishing at the step-counting level for a while now, because it’s a really difficult thing for a company to take on moving to the next level and providing medical advice. From what I can tell even Apple has run into this. Maybe a new type of company will be needed, some strange hybrid of tech, pharma, insurance, and lifestyle? My guess is that this is still several years out. Who knows. But it’s too important to ignore.

Anyway, the main reason that I say health is that the benefits are inherent to the form factor: in other words, this is not really something your phone can do a great job at, it needs to be something that’s attached to you all the time.

A close second for me is fine-grained location-based services, like the types that will be enabled by Estimote Beacons. GPS enabled a whole new set of products from Google Maps to Uber to Strava to Foursquare. And GPS is pretty coarse! Knowing how close a user is to a specific point in space will open up a whole new set of possibilities. And wearables seem like the ideal way to situate a person in relation to these places, and interact with them. So there’s this convergence of emerging trends – wearables, precise location mapping, Internet of Things, context engines – that feels like it will eventually all combine something brand new. It just unlocks a whole new set of off-screen experiences. This seems much more immediately achievable than the health stuff, because all of the necessary tech basically exists already, we just need developers to invent the experiences and I think a Cambrian explosion of new ideas is now right around the corner. What the app ecosystem was to smartphones, nearables and connected devices will be to wearables.

All the other stuff – better notifications, voice search, payments – may certainly be great enhancements. They may even be better that doing the same thing on the phone, and that’s worth a lot. But they probably won’t be the fundamentally new experiences that wearables enable.

WB:What’s your idea of a killer wearable app? Or maybe it’s already out there?

EC: A watch that constantly displays my exact calorie surplus or deficit for today. Calories consumed versus calories burned.

We have all these insanely enormous diet and exercise industries, and they all basically boil down to: don’t consume more energy than you expend. Every one of them, that’s it, they’re all variations on that theme. Directly addressing that equation could cut out a lot of nonsense.

It’s definitely not out there already. Some apps estimate your calorie burn as a factor of estimated movement, but it’s imprecise. And there’s no automatic solution to calories consumed, which is what you have all these painful meal entry apps.

A ton of services could be built on top of this, but that’s basically it.

WB:Moving on to contextual computing: how important is user context in wearable interfaces?

EC: The question of how to interact with these devices came up early. The screen is tiny, so it’s going to be kind of a pain to swipe around and launch apps, right? This became a key question for us on Android Wear.

So then we asked ourselves, what are we launching these apps for anyway? I mean, it’s a pain to find and download and maintain all of these apps anyway, so what are they really for? They’re mostly for accessing content or performing an action of some sort. Now look at these devices, they’ve got small or maybe even no touchscreens, but they’ve got loads of other sensors that can detect the situation the wearer is in. So rather than resisting the natural strengths and weaknesses of wearables by tacking on this legacy UI model from phones, we tried to think about the interaction that was native to the new devices. And that was to use these sensors to detect context, and then automatically offer up the right information at just the right time.

So this solved a local UI problem for wearables, but more broadly, I think that context is becoming the most important trend in modern computing. The bother of managing apps, having to look up information, basically performing digital chores, none of that is really specific to wearables. The automatic grunge work is the stuff computers are supposed to be good at! We shouldn’t have to be doing all that stuff!

So you see this trend of doing things contextually appear in other places too, and it’s fueling new interactions. What you folks are doing at Estimote is a clear example of this, where things can happen automatically based on what I’m near rather than me having to jump through hoops. It also means that messages can be targeted to people at exactly the right time, such as when they walk into a certain area.

That’s also a big part of what I’m now working on with Intercom. Our mission is to make internet business personal. A big part of this is making communicating with customers contextual – enabling businesses to send the right message to the right customer at the right time. The problem of notification spam is probably going to get worse before it gets better, and exacerbated by wearables, so for me it’s a hugely important problem to be working on. We’re taking a totally new approach to messaging – contextual targeting based on in-product behavior, as well as other factors. You could apply this approach to almost any existing product. There’s a ton of new things that we can do based on context that wouldn’t have made sense under old models.

WB:iBeacon and nearables give mobile devices location context. What should developers watch out for when integrating them into wearable apps?

EC: Again, I wouldn’t make a huge distinction between wearables and non-wearables here. Any computer you’ve got with you should be treated the same. If we are indeed moving into a period where I might be carrying more than one connected device at a time, it’s likely we’ll see a move away from a targeted, device-specific approach to notifications and start thinking of this as a constellation of interconnected devices.

For me the challenge for nearables (which I love as a term, BTW) is the same as for any devices pushing information to a user: keeping it timely and relevant. There’s a big risk of coming off spammy and annoying, which would obviously be a horrible user experience and something to look out for.

WB:Do you see location and proximity-awareness unlock any new uses for mobile and wearable devices, that haven’t been explored before?

I do, but just like it would have been difficult to look at GPS and predict that Uber would become an inevitability, it’s hard to say what exactly they might be. Lots of people have been throwing around the old “get a coupon when you walk by a store” idea for many years now, but once the obvious stuff has been worked through the interesting edges will start to emerge. All of these things will be iterative and need to develop organically, although I’m sure it will also happen quickly.

WB:Is there an existing use case for iBeacon, geofencing, or another location-based service that made you say “oh snap, that’s cool?”

EC: The user experiences that Disney are creating with their Magicband system sound amazing. It’s interesting, because so many of these systems have a chicken-and-egg problem: it’s not worth creating a network of beacons without widespread adoption of wearables, and one of the main reasons to adopt wearables might be to interact with beacons. But Disneyland doesn’t have that problem: it’s this hermetically-sealed, tightly-controlled environment thaat is totally mediated, so in that sense it’s actually really interesting as a large-scale experiment. And by the sound of things they’re doing something really compelling.

That’s kind of how I see the wearables ecosystem bootstrapping itself, by the way: build up critical mass with notifications and basic movement tracking, which leads to widespread use of beacons. That in turn leads to broader wearable adoption, which eventually leads us to the point where serious health features become widespread. At which point we have all achieved wearable computing nirvana and it’s time to move on to “swallowables!”

Emmet Connolly: Director of Product Design at Intercom. Previously Android Wear instigator, Google[x], Google Search.

New technologies often face initial consumer confusion about whether they may be used maliciously. iBeacon is no exception. Over the last year some press reports have written about tracking beacons and raised some alarm among the public with a number of worrisome scenarios. That’s why we want to clarify how Estimote is taking effort to assure our customers treat users’ privacy very seriously and why beacons are not designed to track anyone.

Asking the right questions

Many customers ask us if it’s mandatory for users to have an app installed on smartphones in order to receive beacon-triggered notifications. And when they learn the answer is yes, some of them want to know if there are ways to work around this. The answer is: no, it’s not possible and we strongly discourage this kind of thinking. Why? Because we believe that one of our primary responsibilities, other than building the product, is evangelizing best practices for deploying beacons. What all clients learn from us is this: begin with asking the right question. And that is not “How do I push messages to people without them installing my app?” but rather ”How do I create a solution with enough added value that users are incentivized to download my app?”

The app requirement has been widely feared as an obstacle standing in the way of widespread adoption of beacons. That’s just wrong. We’re convinced it’s actually one of the greatest things about iBeacon. It puts focus on the opt-in part of the experience. Pushing meaningless ads to people is easy enough already. So easy, in fact, that we as a society have developed “banner blindness.” And that’s exactly what we want to avoid with beacons and precisely why the opt-in element of iBeacon matters. If you deliberately download an app and opt in, you will not be blind to its content. You are clearly signaling your intent to receive and consume that content. This dynamic is at the core of our philosophy.

If brands and businesses deliver clear value, providing users with engaging experiences and minimizing the friction between physical and digital, they won’t have to worry about needing an app. People will be eager to install and actively use those apps – whether it’s about helping visually impaired in public transport, finding your way around a huge event, or just quickly grabbing a coffee in Palo Alto. It would be shortsighted to think otherwise: at this stage of iBeacon development, each low-quality deployment can harm the perception of the whole technology and slow down its growth.

Can beacons track you?

Asking the right questions is about educating our customers. But we also want to help educate and reassure our customers’ customers: the end users. And a primary question end users and the general public has is whether beacons can track them. No, they cannot.

Beacons are pretty straightforward: they simply broadcast a one-way radio signal. In addition, the Bluetooth Smart standard is designed to transmit very small packets of information, so it remains as energy efficient as possible. Therefore, the only data contained in an iBeacon signal are the ID of an individual beacon and information used by mobile devices to estimate proximity. So without an app that knows how to look for a particular set of beacons (i.e., those beacons’ unique identifiers) - and to which you have explicitly opted in - a retailer/brand (or other venue with beacons deployed) won’t be able to detect your presence.

Alright, so beacons themselves have no way of tracking you. But what about the apps? Apple is known for their sensitivity about users’ right to privacy. If you want your application to utilize iBeacon, you need to comply with their guidelines and permission system (read the explanation of iOS 8 Location Services on our Community Portal). This means your app has to explicitly ask for user permission to be able to constantly access their location data. And even then, it still has to repeat this question from time to time. A user can always opt out with a tap of a button. Any app that doesn’t comply will find itself rejected during Apple’s app review process.

Going further, how do we at Estimote ensure that after you opt in to an app, that very app isn’t using your data in an undesirable way? First and foremost, by educating our developer community. Data can be collected and used to improve existing solutions. It’s even more true in the age of contextual computing, when knowing your consumers better means being more relevant. Take a look at Google Translate: they wouldn’t be able to create arguably the best online translator without storing billions upon billions of user queries that they use to refine their translation software.

But not every company builds their product with such a noble intent. We’re well aware of that and that’s why we’re optimizing for the end user. Estimote was founded in the heart of Europe and as such, the region’s care and sensitivity for privacy concerns are also a part of our corporate DNA. It’s what drives us to work tirelessly on improving our security mechanisms. But we’re not stopping there. We know all the MAC addresses (unique identifiers for wireless devices) of every beacon we’ve ever manufactured. This means we can also link each unit to a particular deployment and identify companies who aren’t following the best practices for data usage and privacy policy. We can then discuss the issues directly with those customers and work together on necessary improvements. Our confidence in this approach is best highlighted in the design of Estimote Beacons and Stickers. They’re colorful and eye-catching, because we don’t believe hiding them from users’ view is the way to go.

User privacy and the general experience of people using contextual apps built on top of the Estimote platform is very important to us. It’s a sensitive matter, but we want to make it absolutely clear: we’re against tracking without consent and any malicious use of collected data. We will always work to gain and keep your trust through honesty and transparency. As always, don’t hesitate to reach out with questions, concerns or feedback, either via our social channels or by email.

Wojtek Borowicz, Community Evangelist at Estimote

Developing iBeacon apps can be hard. Not only do you have to take into account a whole new dimension of the user experience (also known as the physical world), but those pesky laws of physics also complicate things. Configuring a lot of beacons in a confined space can get messy; we probably know this better than anyone, with thousands of them scattered around our offices. So we’re excited to announce an update to make your (and our) lives much easier. The latest version of our app now includes Flip to Sleep, a neat new feature that lets you “mute” a beacon by simply turning it upside down.

Conditional broadcasting

If you’ve ever worked on a project involving tens of beacons (or hundreds, or thousands…), you probably remember that configuring them wasn’t the easiest thing on earth. If you had one pre-defined setting for all of them, that’s fine: you can just update the whole batch using Estimote Cloud or our iOS app. But if you had to connect to each one to set it up in a particular way, you would spend more time trying to figure out which beacon is which than actually changing their settings.

At some point, you would probably go the DIY-Faraday cage route and do something like this:

… or this:

Well, we’ve been there ourselves too:

But that all changes today. No more locking beacons up in your oven or fridge or wrapping them in aluminum foil to shield the signal. Conditional broadcasting, and the aforementioned Flip to Sleep mode in particular, solve this once and for all. After you enable it on your beacons, you can just turn them upside down and they’ll stop broadcasting. Put them in motion or turn to the original position, and they’ll resume broadcasting again.

Of course you can use Flip to Sleep in more creative ways than just as a substitute for a microwave oven when configuring beacons. It also comes in handy when you’re testing enter and exit region triggers. Up until now, you had to physically walk out of a beacon’s range. Good for your workout routine, not so much for app development. Removing and reinserting the battery to simulate entering a region is also a far cry from an optimal solution. Flip to Sleep comes to the rescue once more, because now you can trigger enter/exit events with as little effort as turning the beacon around. You might also want to use it for preserving battery life: especially if you’re using beacons from the early batches (2013 to mid 2014) that came with smaller batteries than the ones we’re shipping now.

All you need to do is update your beacons to the latest firmware (3.0.1) with the Estimote app or the SDK. Then connect to a beacon and scroll down to the ‘Sensors’ section. Tap on ‘Beacon in motion’, turn on the accelerometer and enable Flip to Sleep. It’s that easy! And it works on all units we’ve ever shipped; it’s based on the accelerometer, which was embedded into Estimote Beacons from the very first hardware version. Remember to turn it off when you install beacons for your production deployment, especially if you’re attaching them upside down (e.g., to ceilings or underneath tables).

Download the latest Estimote app (version 2.12) to enable Flip to Sleep and enjoy the ease of mind.

Flip to Sleep is not the only conditional broadcasting mode available with the latest firmware. Using the SDK, you can also enable Motion only. With this feature turned on, the beacon will only broadcast when it’s moving. It allows you to preserve battery life even further and create beacon-based interactions with movable objects like doors, chairs, or cars.

Help us solve your problems

We’ve made it our priority to release features like remote fleet management, batch update, and conditional broadcasting because we’ve heard from you that configuring and managing beacons is a pain when deploying at scale. We’re constantly striving to embody some of the central lessons we learned during Y Combinator, specifically “talk to your customers and build something people want.” We’ve learned that developers want tools that make it easier to build their own amazing products. So we want you to help us identify the biggest pain points of the development process for beacon-enabled apps. What’s hard, what’s confusing, what’s unclear? We’ve just opened a new thread on our Community Forums where you can share those issues. We will be watching it closely and adjusting our roadmap accordingly.

Of course, you can always reach us via email and on Twitter. Tell us what you think we should improve to make integrating iBeacon into your apps easier…. or how much you love Flip to Sleep!

Wojtek Borowicz, Community Evangelist at Estimote

Getting started with developing beacon-enabled apps is fairly easy: (1) grab a dev kit, (2) download the Estimote SDK and (3) go through a simple tutorial—but it takes much more to build a successful beacon-powered experience that’ll win the hearts of the users of your mobile app. Sooner or later, you’ll face the challenge of deploying and managing the very backbone of such an experience: your beacon network. It might be a single venue or it might be multiple ones spanning dozens of cities or even countries. In any case, you want to stay on top of it all—and Estimote Cloud is here to help with that, now allowing you to organize your beacons with tags, their geolocation, and change even more of their settings with the remote fleet management feature.

We’ve heard you like context …

From the very first version of Estimote Cloud, you could assign names to your beacons—an easy way to keep track of them. After getting your first dev kit, you start with a simple “mint”, “ice” and “blueberry”. Then you order some more and set out to do your first, small pilot deployment and the names are now “main entrance”, “side entrance”, “big room beacon 1,” etc. Finally, you start deploying more and more beacons and you end up with monstrosities like “NYC, 46th street, floor 1, NE wing, PoS 6”. Oh, believe us, we’ve been there! Well, there’s a better way now: let’s dive into tags and geolocation.

… so we put more context in your context …

Imagine a multi-level department store with cash registers on each floor. You want your app to provide a seamless checkout experience when the user approaches a Point of Sale—it could be mobile payments or maybe something as simple as automatically pulling out the user’s loyalty card. For the app, it doesn’t really make any difference if the PoS is on the first or the second floor, so you just go ahead and assign a single major value to all the PoS beacons.

From a beacon network maintenance perspective, however, some extra information beyond just a major value would greatly simplify your life. For instance, what if all the cash registers on the second floor were spread further apart than those on the first floor and you wanted to remotely bump the broadcasting power of all the second floor beacons? By tagging them all with the appropriate floor number, it’s as easy as punching the tag name into the search box, clicking the “select all” checkbox and hitting the “edit” button. Our remote fleet management will do the rest!

Tagging your beacons is extremely easy: select the beacons you want to tag, click the “edit” button, pick one of the existing tags from the “tags” dropdown or add a new one, and wrap it all up with the “save changes” button.

While mainly designed to better organize your beacons, tags can also add additional context to your app. Once a “did enter” event triggers off the generic PoS region and the user opens the app, you can scan for the closest beacon and use the Estimote Cloud RESTful API to fetch its details—including a list of tags. You’ll then know exactly which floor the user’s on or whether she’s at the VIP PoS (providing you tagged them accordingly, of course).

Here’s some example Swift code you could put inside your didRangeBeacons delegate, assuming that the beacon variable holds a reference to the nearest beacon:

let session = NSURLSession.sharedSession()
let authString = (":" as NSString)
    .dataUsingEncoding(NSUTF8StringEncoding)!
    .base64EncodedStringWithOptions(nil)

let beaconUID = "\(beacon.proximityUUID):\(beacon.major):\(beacon.minor)"
let request = NSMutableURLRequest(URL: NSURL(string: 
    "https://cloud.estimote.com/v1/beacons/\(beaconUID)")!)
request.setValue("Basic \(authString)", forHTTPHeaderField: "Authorization")
request.setValue("application/json", forHTTPHeaderField: "Accept")

let dataTask = session.dataTaskWithRequest(request) {
(data, response, error) in
    let beaconDetails = NSJSONSerialization.JSONObjectWithData(
        data, options: nil, error: nil) as! NSDictionary
    let beaconTags = beaconDetails["tags"] as! NSArray

    if beaconTags.containsObject("vip pos") {
        // ...
    }
}
dataTask.resume()

We’d be very keen to hear your thoughts about utilizing tags as an additional layer of context in your apps—we’re considering adding native support for tags to our SDK’s ESTCloudManager and your feedback will help us drive this decision!

… so that you can locate while you locate!

If your beacon network spans not just multiple rooms and floors, but also multiple geographical locations, and you’re about to start tagging all your beacons with cities and street names—let us stop you there and talk about supplementing your beacons’ tags with geolocation instead.

Estimote SDK 3.1.0 comes with two new methods in the ESTCloudManager that enable you to assign a geographical location to your beacon. This location is stored in Estimote Cloud, and we also perform a reverse geocoding operation to translate the raw latitude and longitude into a human-readable (and easily searchable!) address.

In its easiest form, you can simply tell the SDK to use standard GPS location services to figure out your current location, and assign that to the beacon:

// don't forget to set the app token!
ESTCloudManager.setupAppID("", andAppToken: "")

cloudManager = ESTCloudManager()
cloudManager.assignCurrentGPSLocationToBeacon(beacon) { (location, error) in
    if error != nil {
        println("error: \(error)")
    } else {
        println("successf: \(location as! CLLocation)")
    }
} 

If you prefer to fetch the location yourself, just use the assignGPSLocation:toBeacon:completion method instead.

And if you want to utilize the beacon’s geolocation as an additional layer of context—just like with the previous tags example—you can do it in a similar fashion:

// follow the code from the tags example up to the
// "let beaconDetails = NSJSONSerialization …" part

let beaconSettings = beaconDetails["settings"] as! NSDictionary
let beaconLocation = beaconSettings["location"] as! NSDictionary

if beaconLocation["city"] == "Kraków" {
    // change the background image to Lajkonik[1]
}

[1] http://en.wikipedia.org/wiki/Lajkonik

One More Thing™

Remote fleet management via the Estimote Cloud has gotten much more powerful since we introduced it last year: you can now not only remotely update your beacons’ broadcasting power and advertising interval, but also their UUID and major, as well as enable power modes and Secure UUID. The next time you open the Estimote app, it’ll automatically download the list of pending changes and—whenever you enter the range of beacons that need updating—apply them in the background. And in case you missed it, your own app can now do this too.

Whether you’re doing a small pilot, or rolling out thousands of beacons across multiple continents, organizing and managing your beacon network has never been easier!

As always, we encourage you to share your thoughts with us—whether on Twitter, our community forums, via email, or even Snapchat*.

* The official Estimote Snapchat account is coming Soon™.

Piotr Krawiec, Technology Evangelist at Estimote

The most important piece of advice we give when starting your beaconified app development journey is to start by asking yourself: what’s the actual user experience going to look like, and how does it benefit the users of your app? Find an answer to these two questions and you can’t go wrong. Today, however, we want to talk about something a tad different: what’s in it for you! Besides a smoother end-user experience in your app, (e.g., not having to punch numbers into the audio guide anymore), which translates to more downloads, there’s a more tangible, immediate benefit from having beacons deployed in your venue and your app equipped with the Estimote SDK: real-world analytics. Today’s update brings improved functionality across the board. Learn what’s new, how to integrate it with your app and how to access the information via our RESTful API.

The iterative approach

We launched the first version of our analytics last year, but the iBeacon market has matured a lot since then—so it was time for an update. With more and more beacons moving out of the proverbial garages of early adopters, and into actual venues, we’ve been gathering a lot of feedback. With a community of 40,000 developers and growing, that’s our release cadence: move fast, put an early version in the hands of our community, listen to your thoughts, ship improvements.

Regions instead of beacons

We’ve redesigned how we gather analytics data so that you’re no longer constrained to individual beacons—which is super useful when you’re working with more than 20 beacons. Because iOS limits the number of beacon regions you can monitor at any given time to 20, sometimes you simply need to group your beacons—instead of creating one region per beacon, which would limit you to 20 beacons.

Let’s say we’re in a museum and there’s this one big hall with a t-rex exposition. Since it’s a big space (the tyrannosaurus wasn’t a small creature), you installed 10 beacons in there to cover its entirety, and assigned them a single major to group them into a single region. Previously, if you wanted to enable analytics for these beacons you’d have to do it on a per-beacon basis:

ESTCloudManager.setupAppID("YOUR_APP_ID", andAppToken: "YOUR_APP_TOKEN")
ESTCloudManager.enableMonitoringAnalytics(true)

for i in 1...10 {
    let beaconRegion = CLBeaconRegion(
        proximityUUID: NSUUID(UUIDString: "YOUR_UUID")!,
        major: 13, minor: CLBeaconMinorValue(i),
        identifier: "t-rex, beacon \(i)")
    self.beaconManager.startMonitoringForRegion(beaconRegion)
}

Now, you can simply do …

ESTCloudManager.setupAppID("YOUR_APP_ID", andAppToken: "YOUR_APP_TOKEN")
ESTCloudManager.enableMonitoringAnalytics(true)

let beaconRegion = CLBeaconRegion(
    proximityUUID: NSUUID(UUIDString: "YOUR_UUID")!,
    major: 13, identifier: "t-rex, all beacons")
self.beaconManager.startMonitoringForRegion(beaconRegion)

… and we’ll keep track of how many people with the museum app installed enter and exit the hall. Of course, you’re still free to stick to more specific regions, but just keep the 20-region limit in mind.

There’s one important implication of us moving from per-beacon to per-region analytics: previously, if you changed your beacon’s UUID, major or minor after it already gathered some analytics data, the data would stay with the beacon. Now, since that data is tied to regions instead of beacons, that data will stay with the previous UUID, major and minor.

New RESTful API endpoints for analytics

Naturally, the analytics themselves are only as useful as the information you can extract from them. So we’ve expanded the analytics endpoints of our Estimote Cloud RESTful API with more high-level reporting in mind. Until now, we gave you access to a daily pings count for a beacon—a ping being somebody entering the range of a beacon. It’s a great metric to quickly assess traffic trends inside a certain area, but apart from that it didn’t provide much more insight. That’s why you can now access two additional endpoints: visits and unique visitors.

Imagine you own a restaurant and one of your patrons is sitting at a table and enjoying her t-rex steak (we’re sure that’s a thing!). While she sits and eats her meal, she remains in range of your beacon. A single ping was registered when she entered the room. But her phone rings, and she goes outside to take the call—coming back, that’s the second ping. Visit to the restroom? A third ping. Clearly, not an ideal metric if you as the owner want to measure the actual traffic in the venue. That’s where the visits endpoint comes in. As long as the pings are spread apart no further than 60 minutes, we’ll group them into a single visit. Suddenly, the patron’s short absence at the table no longer affects the analytics data. And if she came in for lunch and then comes back in the evening (who wouldn’t want to frequent a restaurant with t-rex steaks?), Estimote Cloud will count that as two distinct visits.

Setting all of this up is really easy. In your app’s code, add:

ESTCloudManager.setupAppID("YOUR_APP_ID", andAppToken: "YOUR_APP_TOKEN")
ESTCloudManager.enableMonitoringAnalytics(true)

let uuid = NSUUID(UUIDString: "YOUR_UUID")!

let entireRestaurant = CLBeaconRegion(
    proximityUUID: uuid, identifier: "beacons in the entire restaurant")
self.beaconManager.startMonitoringForRegion(entireRestaurant)

let room1 = CLBeaconRegion(proximityUUID: uuid,
    major: 1, identifier: "beacons in room 1")
self.beaconManager.startMonitoringForRegion(room1)

let room2 = CLBeaconRegion(proximityUUID: uuid,
    major: 2, identifier: "beacons in room 2")
self.beaconManager.startMonitoringForRegion(room2)

And then you can access the data like this:

curl -u <WEB_APP_ID>:<WEB_APP_TOKEN> -H 'Accept: application/json' \
https://cloud.estimote.com/v1/analytics/<YOUR_UUID>:1/visits?↩
↪resolution=daily

# example response:

{
  "region": "<YOUR_UUID>:1",
  "unique_visits": [{
    "time": "2014-04-01T12:00:00",
    "app_in_foreground_visits": 34,
    "app_in_background_visits": 53,
    "total_visits": 86
  }, {
    "time": "2014-04-02T12:00:00",
    "app_in_foreground_visits": 41,
    "app_in_background_visits": 38,
    "total_visits": 79
  }, {
    …
  }],
  "timezone": "America/New_York"
}

Continuing the restaurant example above, here you can see that on the 04/01 there were 86 visits to room 1 of your restaurant and on 04/02 there were 79. We also give you a breakdown of how many of these visits happened with your app entirely in the background (app_in_background_visits) or if the user has opened your app at least once throughout the visit (app_in_foreground_visits).

But wait, there’s more! You can now customize the time period you’re interested in (the from and to parameters, defaults to “one week ago till now”), and also decide whether you want the data grouped by days or hours (the resolution parameter, defaults to “hourly”). Say this time you’re interested in how many unique visitors came in during lunch hours on April 1st:

curl -u <WEB_APP_ID>:<WEB_APP_TOKEN> -H 'Accept: application/json' \
https://cloud.estimote.com/v1/analytics/<YOUR_UUID>/unique_visitors?↩
↪from=2015-04-01T11:00-05:00&to=2015-04-01T14:00-05:00&resolution=hourly

# example response:

{
  "region": "<YOUR_UUID>",
  "unique_visitors": [{
    "time": "2014-05-01T11:00:00",
    "app_in_foreground_visitors": 8,
    "app_in_background_visitors": 6,
    "total_visitors": 14
  }, {
    "time": "2014-05-02T12:00:00",
    "app_in_foreground_visitors": 16,
    "app_in_background_visitors": 23,
    "total_visitors": 39
  }, {
    …
  }],
  "timezone": "America/New_York"
}

How do we understand a unique visitor? The Estimote SDK generates a unique, anonymized identifier whenever a user installs and runs your app for the first time. We then send this identifier with every single analytics event (such as somebody entering the range of a beacon). When you request the unique visitors data for a certain timespan, we’ll check how many unique identifiers came in with all the events within that period, and present it to you.

Monitoring AND ranging

The final improvement to Estimote’s analytics which we’re really excited about: you can now gather data not just from monitoring events (i.e., enters and exits), but also ranging. Since ranging beacons gives very detailed information about every single beacon detected nearby, and is not limited in any way (like monitoring), this allows much more fine-grained data collection.

Coming back to the museum example: you’re now gathering analytics for the whole “t-rex” region of 10 beacons—which enables you to save 9 monitoring slots for other regions—but maybe you’re still interested in getting data from individual beacons when the app is in the foreground and can range beacons without limits. Well, as long as you have analytics enabled in the Estimote SDK, that’s exactly what will happen!

ESTCloudManager.enableRangingAnalytics(true) // *NEW*

let beaconRegion = CLBeaconRegion(
    proximityUUID: NSUUID(UUIDString: "YOUR_UUID")!,
    major: 13, identifier: "t-rex")
self.beaconManager.startMonitoringForRegion(beaconRegion)
self.beaconManager.startRangingBeaconsInRegion(beaconRegion) // *NEW*

…

# data from monitoring, the whole "t-rex" region
curl -u <WEB_APP_ID>:<WEB_APP_TOKEN> -H 'Accept: application/json' \
https://cloud.estimote.com/v1/analytics/<YOUR_UUID>:13/visits

# data from ranging, an individual beacon (minor: 1) in the "t-rex" region
curl -u <WEB_APP_ID>:<WEB_APP_TOKEN> -H 'Accept: application/json' \
https://cloud.estimote.com/v1/analytics/<YOUR_UUID>:13:1/visits

Voilà! You deserve a solid t-rex steak now.

And remember, even as these new beacon analytics tools continue to get more powerful, never compromise having a strong bias toward the end consumer value.

More to come

The update to the Estimote’s analytics is ready today—go try it out! (Hint: as with the first version, analytics works with Secure UUID beacons too.) We’re eagerly looking forward to hearing your thoughts, so that we can continue to iterate. What kind of API endpoints would you like to see next? Any additional filters that would come in handy? How do you anticipate using the data from the real-world analytics to optimize your venue? Make sure to let us know—on our forums, Twitter, or simply drop us an email.

Enjoy the number-crunching!

Piotr Krawiec, Technology Evangelist at Estimote

Today we’re thrilled to announce that we’ve updated both the Estimote SDK and Estimote App for Android. We overhauled both and they’re ready for action! The biggest update is integration with Estimote Cloud, which should alleviate many security concerns and simplify your life when it comes to managing your beacons. The updates are available on GitHub and in Google Play.

Enter Estimote Cloud

The latest version of our Android SDK (version 0.6) introduces Estimote Cloud integration and cloud-based authentication. This means that you need to provide your app ID and token to be able to connect to your beacons. It prevents unauthorized access and saves any changes made to beacon settings in the cloud. You’ll be able to immediately see them take effect in the Estimote Cloud dashboard. The new SDK also enables you to update the firmware of your beacons to the latest version: 3.0.1. We highly recommend keeping your beacons’ firmware up to date. The latest version not only enables much tighter security for your beacon network, but also brings cool features like conditional broadcasting. You can read in detail about the new firmware elsewhere on our blog.

The updated SDK is available on GitHub.

The changes above apply to the Android version of our app too. It now features cloud integration and will require you to log in to your Estimote Account to be able to make any changes to beacon settings. If you don’t have an account yet, it takes just a moment to sign up for one. The app also allows you to update your beacons’ firmware.

You can download the app from Google Play.

Take note

If you’ve been using our Android tools to date, a critical thing to note: if you have used them to change the IDs (UUID, Major, Minor values) of your beacons, those beacons are currently desynchronized with Estimote Cloud. We strongly recommend putting them back in sync.

To do so, please connect to each beacon with the new Android app. It will prompt you to reset the ID to the factory settings. After you do that, you’ll be able to adjust UUID, Major, and Minor to your liking once again. It’s a one-time issue stemming from the fact that the Android app and SDK were not integrated with cloud before. After you synchronize your beacons with Estimote Cloud, you won’t need to do it again.

Coming soon

This is just the first in a series of updates that are coming to our Android tools. In the near future we’ll ship many more features we’ve already introduced for the iOS platform. This includes, among others, Estimote Stickers detection, sensor data support, and deeper integration with Estimote Cloud. And if you want to learn more about our tools for Android developers, don’t hesitate to ask on the Estimote Community Forums or by tweet and email.

Employing beacon technology to deliver indoor location solutions requires a deep understanding of the physics behind Bluetooth and beacons. We firmly believe that’s a challenge with which you shouldn’t have to be concerned. Our goal at Estimote is to abstract away the difficulty of building context-rich mobile apps by providing best-in-class developer tools. Indoor location is a particularly hairy challenge, but one that our engineering team is especially excited to tackle. We’ve taken a very hands-on approach to improving our Indoor Location SDK by constantly walking around our office to test the accuracy and stability of the product – in fact, we’ve traversed a length equivalent to several marathons!

Today we’re releasing a substantial update to the Estimote Indoor Location SDK that delivers increased precision, responsiveness and stability, along with a set of features that make it much more extensible for larger real-world environments.

Download the updated SDK from GitHub. Estimote Indoor Location is now also integrated with Estimote Cloud, so you can manage changes and share locations more easily. Read more to learn the details.

The crawl, walk, run approach to iterating Estimote Indoor Location

The very first release of our Indoor Location SDK allowed for navigation with accuracy of about 1.5 meters in small locations. Though the accuracy and stability wasn’t always perfect, we felt it really important to focus on refining the tech in smaller rectangular spaces first. Doing so has allowed us to gather tons of feedback from our developer community and continually refine the SDK in our own tests, particularly with an eye toward making it suitable for larger, more irregularly-shaped spaces. Today’s release is a culmination of tons of improvements over the past half year.

A major component of our work on this SDK release was improving positioning stability, a notoriously hard problem to solve. Compared to previous versions, user movement is now noticeably smoother and less prone to drifting in the wrong direction or failures caused by sudden movements (e.g., shaking or dropping the phone).

The updated SDK also enables better UI display of positioning accuracy, represented by a circle drawn around the avatar, just as in popular GPS navigation services. In addition, if the SDK loses the user’s position, we can now recover it much faster when the user is close to a beacon.

In its first iteration, our Indoor Location SDK was limited to small locations. As we gather more data and improve our algorithms, we continue to optimize it for use in much larger spaces. The current release was tested in a 600 square meter building and we achieved accuracy of less than 4 meters on average (again, with much more stable readings than before, which requires a tradeoff on responsiveness).

On top of that, Estimote Indoor Location is now much better at recognizing when a user has left a given location. Previously it would require the phone to leave the range of all beacons. We designed it this way to avoid false positives, but because we now know the position with more confidence, we can log leaving a room just a few seconds after you cross the border.

Mapping calibrated locations to Estimote Cloud

If you have created any locations using our Indoor Location app, you can now access them in Estimote Cloud. After you log into your Estimote Account you’ll notice a new tab in the web dashboard: Locations. There you can look up a map along with orientation and dimensions plus information about the beacons that are set up in that space. Managing locations in the cloud is now also possible through the SDK. ESTIndoorLocationManager allows you to add, remove, and fetch locations. And because we’ve added geotagging to beacons, soon you’ll be able to tie locations with particular addresses in the Locations view.

Here’s how to fetch one of your locations from the Estimote Cloud and use it in your own app with the Indoor SDK:

ESTConfig.setupAppID("", andAppToken: "")

locationManager.fetchUserLocationsWithSuccess({ (response) in
let locations = response as! [ESTLocation]
if let kitchen = locations.filter({ $0.identifier == "my-kitchen" }).first {
    self.location = kitchen
    self.locationView.drawLocation(self.location)
} else {
    println("location not found")
}
}, failure: { (error) in
    println("error when fetching locations: \(error)")
})

One more thing…

The updates don’t stop there. You can now see how many people are in a mapped location and see their movement in real time!

Simply mark a location as public during setup to allow Indoor Location app users to see it listed among Public Locations if they’re nearby and navigate around the space. The UI supports multiple people at once and allows you to see how they’re moving in real time. If you’re concerned about user privacy, don’t be: we value it a lot. Avatars visible in the Estimote Cloud interface are anonymized, so it’s not possible to identify a person with this feature.

Managing public locations is still in early phases of development, so detecting them is currently only available via the Indoor Location app. In the coming weeks we will also add it to the SDK, so developers can integrate the feature with their own applications. And because beacon networks can allow one venue to enable multiple apps, you can already start thinking of ways to combine public locations with infrastructure sharing.

We’re excited for these new features and all the improvements yet to come. Play with public locations and the other updates and let us know your thoughts. There’s a whole section on our Forums to discuss the Indoor Location SDK, and we’re always reading your emails and tweets. Your feedback is invaluable to us!

Agnieszka Kaczmarczyk, Data Scientist at Estimote

Wojtek Borowicz, Community Evangelist at Estimote

All around the world, smart developers keep building iBeacon apps that help navigate shopping malls and sport stadiums, provide contextual information in museums, or let you order food to your table straight from your phone. At the same time, many engineers set out to implement entire platforms that make it easy for non-developers to benefit from the contextual computing revolution—be it content-for-real-world management systems, mobile payment services or smart office solutions. With today’s release of OAuth support in Estimote Cloud, these platforms can now make it easy for their users to grant them access to their beacons. Just like Spotify can populate your friend list from Facebook, it’ll now be super simple to automatically download a list of your beacons to your favorite CMS, let it manage their settings for you and tap into the whole power of Estimote Cloud—all through the third-party dashboard.

OAuth support is in beta right now: shoot us an email for access.

OAuth-what?

At the dawn of the Internet, if you wanted a third-party to access your account, you had to give them … your password. Yes, dark ages indeed.

Okay, this was actually from 2010 …

Obviously, such an approach comes with numerous security implications. You give away full access to your account. There’s no way to revoke it without changing your password. If you do change your password, you have to re-equip every app with the new one. Really, don’t try this at home.

Fortunately, the Avengers OAuth came along to remedy the situation. OAuth is an open standard for authorization which provides client apps (like the website above) a secure access to resources (posting a new tweet) on behalf of their owner (oh hey, that’s you).

But as it turns out, OAuth proved to be about much more than just securely allowing other apps and websites to access your account without giving up your password. Together with open APIs, they became to apps what hyperlinks are to web pages, helping make the web more interconnected than ever.

The world of connected apps

A code inspection tool that taps into your existing GitHub repos, instead of having you upload the code? A live-streaming app with a Twitter-powered chat, so that you don’t need to build yet another social network? An analytics dashboard for Instagram, making it possible for brands to use it as another marketing channel?

All of this wouldn’t be possible without open APIs. They allow developers to create entirely new apps on top of existing platforms, extending what’s possible—sometimes in ways the original maintainers of the platform wouldn’t even imagine. And this in turn attracts users. Could I host my git repositories anywhere? Sure thing, but then I’m missing out on somanyawesometools that easily integrate with my GitHub repos thanks to GitHub’s RESTful API and OAuth support.

At Estimote, we love our Slack integrations, and none of us can imagine an iPhone without an App Store. We want to give our community of makers the very same freedom to extend and build on top of our platform. More than that, we’re confident that iBeacon can only ever reach mass-adoption if there’s a thriving ecosystem of diverse apps and tools to easily enable contextual experiences.

Earlier this year we opened up our fleet management API, so that you can come up with your own beacon management tools or integrate them with your own platform. This means you’re no longer tied to Estimote Cloud’s web dashboard or our Estimote iOS app for fleet management, but can still utilize our infrastructure without building everything from scratch. It comes alongside the remainder of our RESTful API, which also gives you unrestricted access to powerful analytics and detailed information about your beacon network (like UUIDs but also e.g., remaining battery life estimations).

Today, we’re adding OAuth support to Estimote Cloud, so that connecting third-party apps and platforms with the Estimote Platform becomes easier than ever. Just imagine that your users can authorize your app to access their beacons with just a few clicks. This feature joins our private beta, so don’t hesitate to apply for access.

How does it work, and what’s in it for you and your customers?

From the end-user perspective, it’s just like any other OAuth authorization flow you’ve seen on the Internet, e.g., when connecting your Airbnb account to your Facebook account.

Once you’ve integrated your platform with our OAuth service, your customers can simply log in to your panel, click the “connect with Estimote Cloud” button and get redirected to Estimote Cloud to grant your app access.

One click of the “Allow” button later and they’re being redirected back to your site with a special code. You can redeem this code for an authorization token that’ll allow you to use Estimote Cloud’s RESTful API on behalf of the user.

What are some of the things you could do? Maybe you’re building a specialized CMS system and want to fetch a list of beacons, so that your customers can easily tie content to particular contexts without having to manually input all the UUIDs. Or maybe you’re working on a smart office platform, and want to automatically group beacons in individual offices by their major values. Just queue up remote changes to beacons’ settings—and if you’ve already implemented remote fleet management via push notifcations in your own app, have them propagate immediately this way.

Think about all the value you can provide to your users—abstracting the complexities of the iBeacon technology away and making it easily accessible to marketers, office managers and other non-developer folks.

The story goes on

We’re committed to our developer-centric approach and will keep providing you—the makers—with tools to help push iBeacon technology forward. Whether this means adding support for mobile apps to our OAuth flow, so that users can grant you access to their beacons directly from your mobile app; alternative ways of allowing access for those of your customers who didn’t sign up for an Estimote Account; or even a seamless way to order Estimote Beacons via your own platform, we’ll work hard to keep our platform open and make it more extensible than ever. Share your feedback on our forums, email us your questions or ping us on Twitter with quick thoughts.

If you want to access the beta version of OAuth for Estimote Cloud, let us know!

Piotr Krawiec, Technology Evangelist at Estimote

Arek Flinik, Senior Software Developer at Estimote

Planning and defining the work of an SDK team is a special challenge in software development. Such teams don’t always have “visible” deliverables in the same way a web or app team do. The team’s work is developer-facing – by developers for developers - and much of the planning is on a deeply technical level. The smart people in the team often have strong opinions about how things should be done, and conflict can arise if we don’t understand the “why” of our work. There’s also what I call the “SDK cave” danger, where losing sight of the bigger picture can lead to a team going badly off track. I’ve regularly witnessed the scenario of an SDK team who disappear from sight to develop the next great thing, only to emerge from their SDK cave to learn that what they’ve done isn’t really what anyone wanted…

At Estimote, we’ve hit on a technique that helps us with these issues, and ensures we talk about “why” and “what” before diving into “how.” We call our approach “blog post driven development.”

In simple terms, before we write a line of code, we start each sprint planning session by outlining a blog post describing what our next release will be. The technique helps us avoid premature discussion of implementation details, instead focusing first on what impact and value we can deliver with our software, as well as making sure we really understand the problems we are trying to solve. Our product owner kicks off planning by suggesting a potential headline for the blog post that communicates the overall theme for the sprint. No-one likes a dull headline, so robust discussions tend to take place from the very start. If necessary, we’ll refine and iterate on this headline immediately. We can normally tell if we’ve hit on a great approach just by our reactions and energy levels. More than once we’ve turned “Boring! Nobody is going to care about that…” into “Wow! Developers will love that…” at the headline stage.

Then, as a team, we’ll put together a list of bullet points for the blog. Explaining our thoughts to the rest of the team out loud is a great test of our own understanding – and of the awesomeness of the feature. Just watch the faces around you. During our planning we’ll also consider how we’re going to explain our work to users – will we ship this with example code, for instance, and what will that example code do? Or should we just make it simpler so it needs less explanation? Will the blog post need illustrations? What does the documentation need to cover? This discussion helps all team members develop product skills, and ensures we think about the wider context of what we are doing. What does this mean for our company? What impact will this have on our developer community? Note that this isn’t about producing vague marketing material – this is about a detailed blog post that describes real, working features.

Planning is “done” when each and every team member understands enough to be able to write a blog post themselves, and we have a skeleton post that we can commit to making a reality during the sprint. It’s a lean approach – we put together just enough of a plan for us to understand what we need to do, without the micro-management of anyone telling us how to do it. Right now each planning session defines a mini product launch – which is incredibly good for morale.

We’ve adapted our Kanban board to suit this way of working – our first column is now “Blog post (a.k.a. ‘why this is awesome’)”. There’s room there for an A5-sized Post-it note with our bullet points. Lean again – just big enough to cover the essentials. The inevitable debates about implementation details are easier to resolve if we’ve all been involved in defining why this piece of work matters, and actually have the “why” visible to all. Try this test with a random development team – ask them why the tasks they are working on are important. Our technique makes sure that all of the team can answer the most important question.

We share the blog post outline as soon as possible with other teams in the company – early feedback is always useful. And when we actually write the blog post, we’ll often collaborate across teams, so we’re seeing the added benefit of breaking down barriers in the company, and different teams getting to know each other better (even across continents).

Blog post driven development is also an alternative way of approaching “definitions of done,” whilst avoiding dull checklists that don’t force you to think for yourself. “It’s not done until it ships” is a well enough axiom to (hopefully) need no further discussion – but for us, it’s not done until it’s shipped, publicly announced, documented, has examples, can be used by a new developer with ease, delights our users, and we’re getting feedback on it.

We also use this technique for any refactoring or housekeeping we need to do in our SDK. The same test holds for this kind of work – if there isn’t a “wow” factor to it, maybe we should rethink. Our internal teams are the first consumers of the SDK, and if we can make an announcement that leads them to say “that makes development faster / makes it easier to test / makes life easier” then we know we are on the right track.

You might say “this is just like user stories.” And yes, the aim is similar – focus on delivering user value. But blog post driven development is like user stories on steroids – our discussions of future announcements help us consider so many different angles and approaches. All too often teams think they are benefitting from user stories by prefixing “As a user I can…” to any old task, whilst forgetting to ask “why does this matter?”. Our starting point is to make sure every member of the team understands “why.” It’s a simple tweak to the process, but the alignment this provides us with is one of the main reasons we’re moving faster and releasing more often than ever before.

Want to engage in blog post driven development and deliver tools for developers building contextual apps? Join our team: we’re hiring iOS and Android engineers.

John Cieslik-Bridgen, Project Manager at Estimote

If you do a Google search for “app discovery is broken”, you’ll get over 45 million hits, including a first page filled with articles on the issue. It’s no longer a question of is it broken but how badly it’s broken. So bad, in fact, that Twitterrific is ranked 100th for the keyword ‘Twitter’. Luckily, we won’t have to rely on the almost decade old, marketplace-based discovery model for much longer. It’s the physical world that’s going to fix it.

What went wrong?

The current model worked fine for some time: it itself solved the issue of discovery years ago. Before the rise of the App Store and Google Play (known originally as the Android Market), the lack of a dominant marketplace made it difficult to find apps. You could spend hours googling for the right piece of software. When I recently asked friends where they got their mobile apps back in the Symbian days, the first thing that came to their minds was… BitTorrent. Then, the iPhone happened and the App Store followed shortly thereafter.

The problem appeared solved. With developers flocking to the App Store and Google Play, users would never have to look for apps elsewhere. Everything they needed would always be one click away, available immediately. It was a win-win situation: people have the apps on hand, developers make money, and so it goes. But as the number of smartphone users grew exponentially (and it still does: it will reach 2.5 billion in 2018), so did the number of apps. Right now, the App Store and Google Play have almost 3 million apps combined. Out of them, 82.8% almost never appear on top lists for any category. When it comes to money, it’s even worse: 1.6% of developers rake in nearly all of it. The competition is so fierce that it’s becoming impossible for new developers to break through. The problem has scaled faster than the solution.

Even if you manage to make your app seen and installed by people, you’re still facing a challenge. How do you keep your users engaged? How do you make sure they don’t forget about your app within 24 hours? According to Nielsen, the average smartphone user has 42 apps installed. Eighty-four percent of people, however, will not use more than 10 apps daily, and 55% will not use more than four. And the average monthly usage, 27 apps, has barely increased over the last few years. So, yeah: mobile is eating the world, but the people who feed it are often hungry themselves

Nielsen

Where’s the fix?

Developers complain that being relevant on mobile is becoming more and more difficult. The decay of the current model has created a situation where you’re either a superstar or a nobody; there’s very little space in between. The good news is that the tech giants building the ecosystems are already taking steps to find a fix. It’s also clear that location context and the physical world will play a huge role in making that happen.

You’ve probably noticed that your iOS lock screen often shows an app icon in the bottom left corner. This Suggested Apps feature is based on geofencing. iOS knows where you are and uses this knowledge to enable you with quick access to a relevant application. If you’re sitting at Starbucks, you’ll see the Starbucks app. If you’re working out in a gym, you’ll see the Equinox app. And if you don’t have the app installed, swiping up from the bottom left corner will take you straight to the App Store, so you can download the right app for your specific context. Suggested Apps also work with iBeacon. This gives the feature much more granularity. If you were walking across an airport, it would be impossible to use GPS geofencing to learn whether you’re at the gates and need your boarding pass, or just strolling through the duty-free zone, where a discount coupon would be handy. Beacons offer a solution.

If you want to learn how to use iBeacon with Suggested Apps, follow our guide in a separate blog post.

The current iteration of Suggested Apps still offers limited utility. After all, it’s only a single slot with no options for customization. You cannot set it up to show the Spotify icon when you get into an Uber. You cannot set it up to show the Salesforce icon when you’re in the office, but replace it with Calendar if you have a meeting in less than an hour. You have no control over which icon will be displayed if two apps share beacon infrastructure to push notifications over the same beacon network. Google’s approach also isn’t very sophisticated yet: they’re experimenting with search results by making them actionable (e.g., ordering food directly from search) and showing in-app content. But this is just the beginning, and both Apple and Google are setting their sights on doing much more with geofencing and microlocation. App discovery will be in the middle of further experiments and new features, because it opens up more ways for monetization, which is the key to a healthy ecosystem. And healthy ecosystem is in the best interest of everyone: software giants, developers, and users.

If you look at the history of Estimote, we never positioned ourselves as a beacon company. From the very beginning we’ve been saying that we’re building an OS for the physical world. Today we’re standing by that vision even stronger. Of course, beacons, nearables, and Indoor Location are all parts of it. But so is the evolution of how apps are discovered, distributed, and engaged with. We believe that the canvas on which developers will build apps in the near future will not be devices, but the physical world: places and situations. We’re getting to the point where you will no longer be thinking about creating an app for the Apple Watch, Android phone, or Windows tablet. You’ll be creating apps for the workplace, for home, for commute, for lunchtime, for a museum, for a night out, for a city: this is the new OS. And everything is a part of it.

Wojtek Borowicz, Community Evangelist at Estimote

Beacons help developers and brands create new experiences on mobile. We’ve already seen a lot of amazing applications which wouldn’t be possible without iBeacon. Yet beacons are not only used to push content. If you already have an app, you can use the Estimote platform to not only gather relevant information about how your customers engage with the physical environment around them, but also leverage these insights to enrich their experience.

Start with the basics

In every how-to article and post about making data-driven decisions, data seems to be clear-cut. Metrics increase steadily week over week, exponential curves are visible from a mile away, and every product change is immediately surfaced in the data. It’s only when you dive into your own charts that you realize how difficult it is to find traces of signal in all the noise. It’s true for A/B testing email campaigns, evaluating new UI flows, and yes, understanding information gathered through beacons as well. That’s why before you write the first line of code enabling Estimote analytics, you should ask yourself: what information are you looking for? What hypothesis do you want to validate?

Let’s assume you have a large store and a widely distributed app. There are tons of things you can measure with beacons. For example, if you create a heatmap of foot traffic and then install new signage: does it impact traffic distribution? You can check which section has the longest dwell time. Maybe it means people can’t find what they’re looking for and a change in layout is needed. Of course, analytics isn’t limited to retail stores: museums or airports can also take advantage of real-world analytics too. And just imagine the potential of deploying beacons in an industrial setting: how much time and money can be saved by improving asset tracking in warehouses?

It can be tempting to try measuring all these data points at once or even come up with more and more tests and launch them together. But to make the best use of the power hidden in data, begin by focusing on a single thing and then iterate depending on the results. Follow the PDCA cycle (plan-do-check-act) and you won’t fall into the trap of generating more noise than signal.

Not pictured: how data actually looks like

Dig into the data

Let’s say you already have a well-distributed app and you want to delve into analyzing foot traffic in your venue–whether it’s a retail store, restaurant chain, or industrial warehouse. Beacons will be helpful, especially bundled with the analytics API we released earlier this year. The most important part of Estimote analytics is that the basic unit for all measurements are beacon regions. A region can comprise a single beacon or 4 billion, so this approach gives you the flexibility to choose what and how you want to measure. Taking an example in a museum, you can create a separate region for each exhibition. Or if you’re running a larger venue, define a single region for each floor and see which exhibition is most popular with visitors. Keep in mind that iOS limits the number of regions you can simultaneously monitor to 20 regions. This means that you’ll either need to stick to this region limit or find a way to shuffle regions. Some methods for dynamic switching include GPS data (e.g., if you have restaurants in San Francisco and New York, you can deactivate monitoring for east coast venues when you detect that your user is physically present on the west coast) or time-based triggers (e.g., in a retail store, activate only regions in aisles with discounted products and then compare different promotions).

At the same time, collecting data from beacons is not limited to region monitoring. You can still leverage ranging to get more granular insight into visitor behavior. After your app’s users enter a region, you can use ranging analytics to find out exactly which beacons they approach. It’s very useful for heat mapping and tracing traffic patterns. Keep in mind that ranging should only be used works if the app is running in the foreground, so if your goal is data collection, you must offer consumer value to drive active engagement with your mobile experiences, not just by triggering actions in the background.

Another data point you can track with Estimote analytics is number of visits. Like Google Analytics, you have the option of differentiating between visits and unique visitors. Depending on your venue type, the healthy ratio of newcomers and known customers will be different, and employing analytics will help with finding the sweetspot. Assume you run a chain of restaurants and have a popular loyalty app. After integrating it with beacon-based analytics, you notice one of the locations has a much higher rate of returning diners. Maybe this indicates that the staff is providing great service and deserve a bonus? However, assuming that the traffic from word of mouth is also high, you would want to look for a spike in the overall number of visits as well. If that isn’t the case, maybe the unusual rate of returning customers is a sign of something else. For example, maybe your Facebook ad failed to attract new customers or that the location is inconvenient.

Ready for some number crunching? Read about how to enable Estimote analytics in this blog post.

Privacy first

We cannot stress enough how important it is to defend your customers’ privacy. Always inform them about the data you’re gathering and how it adds to the overall experience. Transparency is key even in ideal cases, like Google’s use of reCAPTCHA to digitize old books and manuscripts. Also, it’s not bad to leverage data for commercial purposes, as long as it improves the customer experience. A great example of that is Amazon: they drive a ton of revenue by upselling you on products they know you want.

Ultimately, the customer should always have the ability to opt in to data collection. At Estimote, we’re working hard to make sure that developers using our technology prioritize privacy. And the iBeacon standard itself is opt-in by design. That being said, you should still go the extra mile to assuage any concerns your customers might have. For example, create your own UI/UX that explains how and why you need permission in the first place.

Like this

Data is a valuable tool to understanding customer behavior and it’s amazing that beacons allow us to derive even more information from the physical world. Making sense of all of this, however, can be tricky. It’s essential to approach beacon analytics with a clear strategy, testable hypothesis, and an emphasis on customer value. Keep these principles in mind and you won’t get lost!

Wojtek Borowicz, Community Evangelist at Estimote

This is a guest post by PencilCase Team at Robots and Pencils Inc

Estimote beacons have unlocked the ability to create mobile experiences rich in context, but the power to implement these experiences has often been limited to developers. Now, anyone can build a beacon-powered mobile app with PencilCase.

PencilCase is an iOS app-making tool that allows non-developers to create native apps for the iPhone and iPad without writing a single line of code.

How PencilCase works

PencilCase is made up of two parts: PencilCase: Studio for Mac and PencilCase: Player for iOS.

PencilCase: Studio is the app maker. To create an app, simply import your creative assets – images, videos, audio and even 3D models – into the Studio and then add the functionality you want to see in the app.

PencilCase: Player allows you to test and share your app on an iPhone and iPad for quick iteration. Once complete, you can publish to the Player and distribute your app’s unique Share Code to customers and employees. You can also export your app as an XCode project and submit it directly to Apple’s App Store.

Create your first Estimote app in minutes

We’re big believers in the philosophy “show don’t tell.” So, rather than telling you how easy it is to create an app that incorporates beacons in PencilCase, we’ll show you instead.

For this demo, we’ve decided to replace paper guides at museums with an engaging visitor app. To see what we created and to recreate it yourself, download a free trial of PencilCase: Studio onto your Mac, and PencilCase: Player onto your iPad. Next, grab the project so you can follow along, and check out the finished product right on your iPad.

The basics

When you open PencilCase: Studio, you’ll see your Cards on the top left-hand side. They represent screens inside your app. You can add, duplicate, delete or rearrange your Cards like you would in Keynote or PowerPoint.

Unlike other app makers, you’re not restricted to a template in PencilCase. You can build UI from the ground up. Just upload your creative assets to the Media Pane and then drag them to your Cards as you create the app. You can also include features like menus, buttons, scroll views and text inputs by using the built-in Supplies, and add slick animations using Physics or Timeline.

Finally, the intuitive Whens & Thens system allows you to create complex behaviors by creating statements that identify the actions you want the user to take (the “when”) and events they trigger (the “then”).

Recreating the home screen

1. The second Card in PencilCase: Studio is our home screen. To recreate it, go to the Media Pane, select the background image (BK1.png) and drag it on your Card.
2. Next, add the top bar navigation by selecting TopBar.png from the Media Pane and dragging it on the Card.
3. To add the navigation bar title, select the Text Label Supply from the Supply Pane and drag also drag it on the Card. While the Text Label is still selected, go to the Properties Pane on the top-right hand side of Pencil: Studio. Underneath the label text section, type in the name of your title.
4. To create the menu along the bottom of the app, you’ll want to use the Scroll View Supply. Drag the Scroll View supply from the Supplies Pane to the Card, and resize it to your desired size.
5. Once resized, double-click to edit and resize the scroll content. If you have several assets to add to your Scroll View, you may need to extend it off of the Card.
6. Then while inside the scroll content, drag your assets from the Media Pane to the Card and arrange them in a horizontal line within the Scroll View. For this example, you’ll want to use Button, Button 1, Feature 1, and Feature 3.
7. Finally, we want the user to be able to navigate to a new screen from the Scroll View. To do this, we need to add a Behavior. Go to the Behaviors Pane on the right-hand side and click on When. Type in the word “tapped” and select “When XXX is tapped.” Click on the underline and select the appropriate asset. For this example, choose Button. Next click “Then” and type in “go to.” Select “Then go to card XXX using transition typeXXX with duration XXX seconds”. Click each underline and complete the sentence with the appropriate information. For this example use “Then go to card NextCard using transition type Instant with duration of 0.4 seconds.” Repeat for each image in the Scroll View.

Adding Estimote Beacons

Now, assume we’ve placed Estimote Beacons around the museum. Rather than the user navigating to information in the app, we want the information about a specific piece of art to appear automatically as the user moves closer to it.

1. To implement Estimote Beacons, go to settings by clicking on the gear icon in the top toolbar of PencilCase: Studio.
2. Under Third-Party, click the “+” button in the bottom right corner to add a new beacon. Input your beacon’s information: UUID, Major, Minor, and a name of your choice. For clarity, the beacon name represents the piece of art it’s associated with. Repeat this step for each beacon.
3. Navigate back to your project by clicking the project view icon next to the gear on the toolbar.
4. Finally, create a Behavior that triggers information about a specific piece of art when they are in proximity to the associated beacon. To do this, go to the Behaviors Pane. Click on the When button, and type in “iBeacon.” Select “When the proximity of iBeacon XXX changes to XXX.” For this example use “When the proximity of iBeacon ApartIX changes to Immediate.” Next, click on Then and type in “go to.” Select “Then go to card XXX using transition type XXX with duration XXX seconds.” For this example use “Then go to card Card 6 using transition type Instant with duration of 0.4 seconds.” Repeat for each Beacon.

3D as easy as 2D

Now we’ve created a home screen with a scrollable menu and implemented Estimote Beacons to create a personalized, content-rich experience. To complete the app, we need to create content for the screens that represent each piece of art. Here, we’ll show you how to recreate the Damien Hirst skull.

What’s unique about PencilCase is that importing a 3D model is as easy as importing an image. Simply add a .dae file to your Media Pane, and then drag the file onto the Card you’re working on.

1. To create the black background, drag a Color Supply from the Supply Pane onto the Card and resize it.
2. Drag out Text Boxes from the Supply Pane to create the title and subtitle. Adjust the font size in the Properties Pane.
3. Finally add the 3D skull by dragging My3DSupply.dae from the Media Pane onto the Card.

And there you have it! You created your first PencilCase app in mere minutes. To see it in action, select PencilCase Player from the dropdown menu on the top left and hit the publish button. Add the Share Code to PencilCase: Player on your iPad. Ta da! Start playing with the app on your device instantly.

PencilCase team

This is a guest post by Moheeb Zara, Community Manager at Octoblu

There has been a lot of buzz about the Internet of Things (IoT) in the past two years–it seems like everyone is either thinking about or doing something with beacons and other connected devices. But what exactly is the Internet of Things? How does it benefit you? What can you build today that is an example of what’s to come? With Octoblu, you can bring IoT into your life today, in a meaningful way with tons of room for experimentation. In this example, we’ll get you set up using Estimote Beacons to create a variety of device-based internet interactions. IoT is about connecting people, places, things, and data and then building seamless interactions between them to improve quality of life.

What is this demo?

Let’s get started on building an Octoblu demo that uses your laptop’s hardware to detect nearby beacon broadcasts. We’ll use this to launch different webpages in your browser. This is an example of a basic use case where your application uses proximity and location to perform various interactions. For example, if you walk into your bedroom, the lights might automatically turn on to your preferred brightness/color. Or maybe you want to know if your dog or cat entered a certain room: you can play an audio sound to train it to stay away or trigger a text message to your phone. These are just a few basic use-case examples. The same principles learned here can be used to build customer loyalty apps, proximity-based marketing, alarms, dynamic environments, and much more.

What is Octoblu?

There are several parts to orchestrating this demo. The first is Octoblu, our web based environment for visually connecting and programming the Internet of Things. Octoblu is also used to manage devices and channel configurations. You can tie your various web services (channels) and connected devices to Octoblu and add logic in between. You can then deploy these interactions as cloud based apps in one click!

Connect Local Hardware through Gateblu

The second part is Gateblu, an application that links local hardware and devices to Octoblu through plugins. We’ll be installing a BLE beacon plugin that lets us see iBeacon broadcasts within Octoblu, where we can program some logic to do something with that information. This way, we can interact with other devices and web services connected to your Octoblu account.

Beacons

The final piece of the puzzle is the Estimote Beacon. The tutorial below, with accompanying video, walks you through using any number of Estimote Beacons to trigger specific actions. In this case it opens different web pages. We’re working to add support for motion, temperature, and even the Cloud API so you can take full advantage of the Estimote ecosystem. Until then, you can use Octoblu to build amazing presence based interactions to control anything from anywhere!

Register an Octoblu Account

The first thing you’ll need is an Octoblu account. Go to app.octoblu.com and sign up! Then be sure to take a look at the Getting Started Tutorial if you need extra guidance.

Install and Register a Gateblu Gateway

1. Download Gateblu for your operating system and run through the necessary steps
2. Once your Gateblu is up and running, press the info button to expose the Gateblu UUID. This is its address, which we’ll need for the next step
3. Go to the CONNECT page in your Octoblu account
4. Select “ADD NODE” and search “Gateblu”
5. From the drop down select “Add an Unclaimed Device”
6. You should see your Gateblu UUID. Select, name, and save it.

Install Plugins to your Gateblu

1. Go to the CONNECT page in your Octoblu account
2. Select “ADD NODE”
3. Select “beacon”
4. It may take awhile to finish initializing
5. After awhile you’ll see some options, leave these blank, name, and save it
6. Follow this process again for the “SHELL” plugin
7. When the options screen shows up, enter “open” for the command
8. Name and save

Import Estimotes Example Flow

This link will take you to an import screen. After importing, you will have a flow in your Octoblu account. It should automatically tie itself to the plugins we just installed. Upon deploying (pressing the play button in the top right), this flow will allow you to open webpages based on the presence of certain beacons. See additional comments if you need help understanding how to tie this functionality to your Estimote Beacon IDs.

Bonus Flow

This flow will show you how to use beacons to trigger different actions based on “near,” “immediate,” or “far” proximity states.

Moheeb Zara, Community Manager at Octoblu

Today, Estimote is excited to announce its compatibility with Eddystone, a new open multiplatform packet format for BLE beacons, released by Google.

Consistent with Estimote’s developer friendly approach, we’re on board supporting the protocol from day one. If you’ve ever purchased Estimote Beacons you can download our newest firmware supporting both iBeacon and Eddystone. Simply download our latest Android app to update your beacons to the latest firmware and you’re ready to start testing Eddystone.

Update your existing beacons today, or buy new beacons that fully support Eddystone technology now.

Internet for the physical world

Eddystone is an open BLE packet, currently comprising three frames: Eddystone-URL for broadcasting URL addresses, Eddystone-UID for broadcasting beacon’s ID, and Eddystone-TLM for beacon telemetry.

Broadcasting URLs with beacons might sound familiar if you’ve ever encountered Physical Web™. Developed inside Google, it’s aiming to bring context of physical locations and objects to mobile devices with websites. Why websites?

There’s an app for that might apply to many activities, but not necessarily to most restaurants, small businesses, or public venues yet. Take a movie theater, for example. The cinema owner may want to make her poster displays promoting upcoming releases more interactive with beacons, but all of her patrons may not have her venue’s app on their phones.

Beyond Physical Web

Of course Physical Web is not a universal answer. In many cases, you will want to create interactions much more complex than displaying a website. Take some of the coolest startups building solutions based on beacons. Downtown makes waiting in a queue to order food a thing of the past. Robin turns offices smart. Stealz changes customers into brand advocates. None of this could be accomplished without a native experience. That’s why beacons supporting Eddystone can broadcast another frame, Eddystone-UID, consisting of a unique ID. Apps can be listening for particular UIDs in a similar manner to how they monitor for iBeacon regions (based on UUID, Major, and Minor values). So if you want to build an app for contactless payments, a museum audio guide, or a home automation tool, Eddystone lets you do that too.

Estimote Beacons also enable you to easily switch between the two frames, to deliver the right experience. Coming back to our theatre example: beacons may broadcast YouTube links to people without the app. But if there is an app and it’s gaining traction, you may want to broadcast the UID to deliver more engaging content, like letting people book a ticket for the next screening with a single tap.

The third frame inside Eddystone protocol is Eddystone-TLM. It comprises data about a beacon’s hardware, like battery level or sensor readings. Frequency of broadcast does not have as big an impact on user experience as the other frames, so our beacons broadcast it less frequently, saving battery life. Eddystone-TLM makes it easier to keep tabs on your beacons. Since hardware status is part of the data packet, you don’t need to connect to a beacon to read it. You’ll appreciate how much time it can save if you’re managing a large network of beacons.

Google built Eddystone with all developers in mind. The whole packet is open and multiplatform. This brings system-wide support for beacons to Android for the first time. So far, if you wanted to build an app that would deliver similar contextual experiences on both Android and iOS, you had to use separate SDKs and choose between one of the available Android frameworks. Eddystone works on both platforms. Plus it’s extensible. It allows for adding custom frames, so you can extend the packet with more data.

See for yourself and reach out

If you want to start immediately discovering what Eddystone is like, head to our Developer Portal, where we describe the protocol in detail. We’ve prepared a brief introduction to the new format that will guide you through the basics of Eddystone and Physical Web.

Estimote has been building tools for developers to create contextual apps for more than two years, and it gets more exciting each week. We’d love to share our excitement with you. If you have any questions and thoughts about Estimote Beacons and support for Eddystone, don’t hesitate to ask. You can reach us on Twitter and the old school way. Happy coding!

Also, on Monday July 20th 10 AM PST we’ll be holding a special webinar about building great experiences with Estimote Beacons and Eddystone. Join us on YouTube!

Lukasz Kostka, CTO, Estimote

Wojtek Borowicz, Community Evangelist, Estimote

Last week Google surprised the mobile world with the introduction of Eddystone: a new, open Bluetooth-based beacon format. The promise of a multi-platform beacon protocol supporting Google services on iOS was one reason the news made waves. And they’re delivering on that promise immediately. Today, Google released an update to Chrome for iOS with support for both the Physical Web and Eddystone. Mobile developers of all types - brands, advertisers and retailers - can now use beacons to broadcast websites directly to Chrome and they’ll be displayed in the iOS Notification Center. Although Chrome’s market share on iOS is much lower than Safari, Google has other ‘home screen’ apps including Maps and YouTube which could natively work with Eddystone and the Physical Web. So this is an exciting first step by Google.

Estimote announced support for Eddystone from day one, so you can already enable Chrome support. Just install our latest firmware on any Estimote Beacon and you can start broadcasting URLs which will be read by Chrome immediately.

Eddystone, Physical Web and Chrome

Enabling all this is the Eddystone-URL packet type, which makes it possible to encode URLs directly into a beacon’s broadcast frame. It’s a simple and elegant solution for directing users to a website or presenting them with a splash page, even one to download your app. And if you have an app on user’s phones, you can get more creative and use deep links, directing users to particular screens in your app after they click through on Chrome.

One of the primary concerns brought up when talking about the Physical Web is privacy and user experience. Consumers hate spam and secret data collection. Google has taken care of these issues with Eddystone. First of all, titles and descriptions of websites will be fetched from metadata, allowing them to be displayed before a user clicks. Also, information about users won’t be saved until they click a link, so the beacon owner will not know anyone was nearby until they visit the website. See more on Google’s Physical Web Cookbook page.

Let’s broadcast!

Below we step through exactly how to make your Estimote beacons broadcast URLs.

First, download our Android app from Google Play (we’re putting finishing touches on the next update to the iOS app that includes Eddystone support). Second, connect to a beacon and update to the latest firmware (currently v 3.1.1). In the settings screen, you should see a Broadcasting Scheme tab: that’s where you select Eddystone-URL. Now, the last step: simply provide the desired URL in the settings and you’re good to go! Your beacons broadcast a web address now.

From the moment your beacons start broadcasting the Eddystone-URL packet, Chrome will display the addresses in the Today view in the iOS Notification Center as long as you’re in range. No additional steps or configuration methods are required.

Don’t worry if you don’t have an Android device on hand. You can also set up Eddystone programmatically, using the Estimote SDK. This and a more detailed explanation of Eddystone’s ins and outs are available on our Developer Portal!

Tip of the iceberg

This is clearly just the first step Google is making toward contextualized experiences. Soon we’ll undoubtedly see the Physical Web integrated into Chrome for Android, which runs natively on billions of Android smartphones around the world. And maybe in the future we’ll receive websites in the form of lighter weight notifications or card suggestions.

It’s clear that the future of Eddystone and the Physical Web goes far beyond just the browser. There are a multitude of ways in which beacons could tie into Google Maps, Google Play, or even Google Calendar (automated room booking and attendance tracking, anyone?). One thing we’re excited about is possible Eddystone support for Google Now. Just imagine cards based on your location serving you ambient content in the background with zero friction. We’re a fan of Google’s bigger vision around beacons here, and as a company supporting both large enterprises as well as smaller developers, we’re thrilled to give you the tools to test and deploy with the Physical Web from day one with the Eddystone and Chrome integration.

If you need any support or assistance don’t hesitate to reach out to us on Twitter or via email!

Wojtek Borowicz, Community Evangelist at Estimote