On HealthKit, Granola, and JSON with Sherbit

This is a guest post by our friend Varun at Sherbit.

Enter Varun.

When building our iOS app, Sherbit, we were faced with a daunting task early on: integrating data from disparate sources and standardizing them in such a way that we could easily and dynamically create beautiful user-facing visualizations.

At first, the solution seems simple. All the services that we integrate maintain a REST API (a URL-based system for delivering data) and as such, our solution was then to build a “Sherbit” API, which would normalize all the third-party data in a graph-able way and send them to the Sherbit iOS client.

The problem is that Apple’s HealthKit isn’t a normal API. Unlike every other data source we integrate with at Sherbit, HealthKit is an iOS API — the acquisition of data happens directly on the device and away from the Sherbit API.

This is is a common problem for app developers trying integrate data from HealthKit. Unless you architect your entire app exclusively around HealthKit, you end up with a lot of messy “if health kit x else y” code. HealthKit integration isn’t a trivial process either — unlike many of the other historical-data driven iOS APIs offered by Apple, HealthKit is complex object-driven API comprising of 30+ distinct classes, multiple protocols, and block-driven execution. This isn’t necessarily a bad thing — the wealth of data available from HealthKit is vast and detailed. Apple provides you with full unit support, dynamic querying options, and a lot more. This is what makes HealthKit stand out from your average Health/Wearable/IoT REST API.

The complexity and uniqueness isn’t the only problem caused by HealthKit. Because the fetching of data is tied to the iPhone itself, you can’t store HealthKit data the same way you can store data provided by REST APIs. Apple does not provide a server facing API for HealthKit, and the iOS client will always be involved in the fetching and storing of data. (This is true for other iOS-centric solutions available from Apple. CloudKit, Apple’s competition to Google’s Firebase and Facebook’s now defunct Parse also does not offer a server-facing API).

These issues can be at least somewhat remedied with Granola, which is a handy HealthKit-to-JSON serialization library, maintained by the awesome people at Open mHealth (who also maintain a number of free and open source projects standardizing the collection, analysis, storage, and visualization of heath & fitness data from disparate sources). Granola quickly and easily converts data from HealthKit into JSON, which is a much friendlier format for what we need to do here at Sherbit. JSON structures can be easily sent to our API, standardized the same way every other kind of data is, made graph-able, and sent to our iOS Client (or any other client we might release).

This means a few things:

Less HealthKit Specific UI Code

Once HealthKit data has been serialized into JSON and sent to our API, we can retrieve it the same way we retrieve any data at Sherbit. This means that code used to retrieve data and turn it into a UI can be re-used for HealthKit.

HealthKit becomes more ubiquitous on your platform

If you’ve got 1 value for “steps taken” on your iOS client, and a different value on your web client, users will notice. By making HealthKit data accessible via your API instead of directly on the device, you can ensure that the same values appear everywhere and not just on your iOS client.

You get access to the power of HealthKit

Many device & services do not offer a REST API, and their data is only accessible via HealthKit. Many users have (sometimes inadvertently) poured tons of data into HealthKit — data which you can’t access anywhere else. Apple has the clout to access data that you likely cannot — along with a user facing app used by many people. Even if you don’t like Apple’s Health.app (I certainly don’t), there are certainly benefits to it being built directly on everyone’s iPhone.

Granola doesn’t compromise details to get JSON structures

Granola serializes everything, and I mean everything, attached to HealthKit data. Vendor information, device serial numbers — literally every field in HealthKit data structures. They’ve already done the work to look at every field in every HealthKit class definition. Even data you didn’t know you had or wanted is available.

Granola has become an essential part of HealthKit integration at Sherbit. Without it, we wouldn’t be able to offer as many HealthKit metrics as we do. We can treat HealthKit just as we treat any other piece of data, and quickly add HealthKit metrics to our app as we see fit. If you work with REST APIs and health data, and you’re considering adopting HealthKit, I would take a serious look at Granola. It will become an indispensable part of your arsenal used to conquer HealthKit.

— —

To learn more about Sherbit, visit their website.