Why You should use the Proximity SDK for iOS or Android with Secure Secure is a very complex feature: we pass information to a beacon to randomly generate new beacon major, minor, and MAC address (or instance ID and Mac address), reset the proximity UUID (or Eddystone-UID), and then we generate and store a cache of data on the phone for all beacons that it should deshuffle, encrypts that data cache, and then finally error checks to see if a beacon has drifted out of sync from the expected value from our API. It’s certainly possible to write all of those features from scratch for your own use in your app, but we think that the time savings inherent in using our SDK are worth including it instead.

I’m going to talk about this in some detail below, but here’s the short version: you will save at least $60,000 in development costs if you integrate our SDK instead of re-inventing our wheel for yourself.

I’ll come back to that number, but let’s first talk a little about what we’ve accomplished with our SDKs. Secure is a pretty complex feature as it is not just translating proximity UUID, major and minor. Getting the deshuffled ID out from a beacon through our API is possible, but it’s a pretty complicated process. Here’s a (somewhat simplified) UML diagram of the major steps that take place:
We’ve written our new SDKs to be almost transparent to user’s application in terms of resources used. We’ve also built it to be very nearly completely modular, so that you can include the relevant elements of the SDK into your application–deshuffling, for example–and don’t worry about the rest.
In addition to the information in our UML diagram above, our SDK also handles a lot of caching, including future shuffled IDs, and then adds an encryption layer. With the cache in place, your app will make as few requests as possible to the Prxomity API, which saves your customers’ battery and reduces network traffic. If a beacon’s battery dies and it goes out of sync with the API’s expected shuffling pattern, the SDK will makes it very easy to still resolve the correct beacon identifier and possibly even fix the desync by always having correct methods for the required task.
Let’s talk about the Proximity SDK for iOS as an example. It was built to support both shuffled and non-shuffled devices out of the box with the same manager class. Turning on shuffle for a device requires a very simple change: just replace KTKBeaconRegion with KTKSecureBeaconRegion and everything else works as before, handled in the background for you.
As Secure is using random major and minor values (or instance ID) it’s not easy to monitor and/or range more specific regions. Due to how we’ve implemented security, only proximity UUID or Namespce ID are predictable and that’s what the app needs to use in order to know if it should react to a beacon. For a number of developers, that’s not an expected use case, so we implementing many features to present the deshuffled major and minor values for the app to monitor and range even though the actual values have been shuffled by the beacon. For monitoring Enter / Exit region, in iOS we have introduced the assistedMonitoringEvents property which helps with faster reaction time to regions state changes. Finally, our SDKs create a simple system for you to share beacons temporarily in a secure fashion with another application, allowing for what people are calling “multi-tenancy” or beacons which have multiple users. An example of that would be an OOH billboard where every month you change who can use the beacon for advertising
And, of course, all of this functions for both iBeacon and Eddystone formats. And (as already mentioned) it’s modular so that you only need to include the parts of the SDK that are relevant to your needs, reducing our SDK weight to possibly just a few hundred kilobytes depending on what you want.
So let’s wrap up a summary of what our SDKs deliver that you would need to write yourself if you’re determined to use our API directly

  • Secure and nonsecure beacon ranging
  • Sending commands to shuffle devices
  • Store regions that the app should listen to and translate them to shuffled values
  • Connecting to API to deshuffle beacons
  • Caching shuffled beacon values on the device for faster response times
  • Improved monitoring of events
  • Beacon sharing
  • Beacon sharing expiration
  • and all the usual beacon configuration and monitoring functionality

So when you think about all of the work that this entails, you can see that duplicating the functionality of our SDK (and, of course, testing and bugfixing it) to integrate it into your own app is not a small task. Let’s compare costs and development times for your team to how long we know it takes to do from scratch because we’ve just done it.  If your developers know how to write for beacons (as ours do) you should expect that writing an integratioon Secure completely directly in your app will take at least 5 staff months per operating system. That’s how long it took us. 🙂 If your developers aren’t as familiar with beacon tech as ours are, it will likely take even longer. When you factor in the average salary for a mobile developer in the US ($70k USD annually) that’s what I mean when I say you will save nearly $60,000 if you integrate our SDK into your app instead of rewriting all of the functionality yourself.
If you have any questions about our SDK or about Secure, please feel free to either hit us up on github for our SDK, drop a line to, tweet us at @kontakt_io or tweet me directly @TrevorLongino and we’ll try to get back to you as soon as we can. 

Contact us