ReadWriteBody is an ongoing series where ReadWrite covers networked fitness and the quantified self.
There’s a lot of enthusiasm about Apple’s newly announced HealthKit software, especially from the makers of fitness apps and connected devices.
I hate to throw everyone into the locker room and turn the cold-water faucets on full blast, but someone’s got to do it.
Here’s an example of the hype that’s getting thrown around:
“HealthKit appears to be a great platform that Strava can use to serve our global community of athletes with more insight about their athletic performance.” —Strava strategy VP David Lorsh
Appearances aren’t everything. The bottom line is that HealthKit is largely geared around delivering very basic vital statistics to medical personnel, and its nutrition- and activity-tracking features are rudimentary at best.
That will limit the adoption of HealthKit to a fairly small set of users intensely interested in tracking vital signs. As Google and Microsoft have found through their past misadventures in online health, that market just isn’t very broad. It’s not clear to me why Apple thinks putting this data on your smartphone will change consumers’ minds.
Meanwhile, apps like MyFitnessPal, RunKeeper, and MapMyFitness will keep ingesting massive amounts of data from their tens of millions of users (who have both Android and iOS phones)—and sharing it broadly through their well-established application programming interfaces. The data they collect about calories in, calories out, and types of activity, may get fed into HealthKit. But because HealthKit’s data types are so limited at present, any useful analysis that helps guide people to better health decisions will have to happen outside of Apple’s health universe.
Down In The Documentation
There’s no need to speculate about what HealthKit can or can’t do anymore. The details are all in the documents Apple has published, as well as a presentation Apple engineers delivered at the company’s Worldwide Developers Conference earlier this week.
It’s clear that Apple had a hard decision to make on what data types to include. Should HealthKit support a wide variety of medical, health and fitness apps, and risk making choices that conflict with developers’ preferences or medical experts’ ideas of what data is most valuable? Or should it focus on a narrower set of uses, and risk disappointment when consumers realize it can’t store the information they’re most interested in?
The decisions Apple made, though, don’t really fall towards either extreme. In the end, they’re just confusing.
Apple, for example, supports a host of options for taking your temperature from your eardrum to your rectum:
HKBodyTemperatureSensorLocation
HKBodyTemperatureSensorLocationArmpit
HKBodyTemperatureSensorLocationBody
HKBodyTemperatureSensorLocationEar
HKBodyTemperatureSensorLocationEarDrum
HKBodyTemperatureSensorLocationFinger
HKBodyTemperatureSensorLocationForehead
HKBodyTemperatureSensorLocationGastroIntestinal
HKBodyTemperatureSensorLocationMouth
HKBodyTemperatureSensorLocationOther
HKBodyTemperatureSensorLocationRectum
HKBodyTemperatureSensorLocationTemporalArtery
HKBodyTemperatureSensorLocationToe
It’s also got a wide variety of nutrients available for recording. It tracks steps, flights of stairs climbed, and Nike’s proprietary NikeFuel measure for activity. It can track the number of times you’ve fallen and your inhaler usage.
Where Apple falls far short, at least in terms of the concepts built into HealthKit, are the useful details of what we eat and how we work out.
There are some basic features for food logging, but there doesn’t appear to be a concept of timing for food consumption, for example, or support for grouping food items into meals. It’s also not clear what kind of food database Apple might tap to match food items to standardized calorie and nutrition information. MyFitnessPal users accustomed to its very rich food-tracking capabilities will be sorely disappointed by anything built purely with HealthKit.
In exercise, HealthKit appears to count numbers of activities and the energy burned in performing them, but that’s it. You can’t even compare that to RunKeeper’s very well-developed Health Graph application programming interface, which has an extensive software vocabulary for cardio and strength training.
Our Prescription For HealthKit: An Intensive Training Program
I asked RunKeeper CEO Jason Jacobs for some perspective on what it takes to build a sophisticated interface for connecting health and fitness apps, since his company did exactly that back in 2011 with the introduction of the Health Graph.
Jacobs says RunKeeper realized that it was best off building apps for consumers, rather than trying to build what Jacobs calls “middleware” for other app developers. It recently introduced a new activity-coaching app called Breeze alongside its eponymous fitness-tracking app.
“It’s really hard, so I wish them luck!” Jacobs told me. “If [Apple’s] not successful, it doesn’t hurt us. If they are successful, it should help us.”
That’s broadly true, I believe, for most of the apps in the fitness category. HealthKit may help them simplify some aspects of data entry, but it’s far too underpowered and unsophisticated to do much on its own.
How Apple Can Slice Up Our Data
The one thing that’s intriguing about HealthKit is its ability to consolidate and reconcile overlapping data from multiple sources. In a WWDC presentation, Apple software engineer Justin Rushing showed how HealthKit could take step data from two different apps, sort it by time periods, and based on the preferences of the user, eliminate redundant data.
That would be great for someone like me, who’s constantly trying new apps and devices which often track the same kinds of statistics, like hours of sleep, steps walked, and even heart rate during a workout. I use MyFitnessPal and connect it with apps like RunKeeper, Pear Sports, and Jawbone Up.
That’s valuable to me because I now rarely have to log a workout in one app and then record it again in another app. The challenge comes when the Up counts the number of steps I take during a run while RunKeeper logs the same activity and estimates calories based on mileage and speed—and they both feed MyFitnessPal data that not only overlaps but often disagrees.
As we add sensors and apps that can passively track our activity, the problem of data overlap will only grow. HealthKit will have to rapidly add more data types and get better at understanding the relationship between steps, calories, and activity, though—otherwise its abilities to reconcile data won’t keep up with the demands of consumers or developers.
It’s important to recognize HealthKit as it exists today as a beginning, not an end, to Apple’s presence in the health and fitness world. There are some valuable things it can bring—things as simple as letting users update their weight once and have that information flow to all available apps. I typically have to enter my height, weight, sex, and age every time I sign up for a new app. A central storehouse for that information just makes sense.
I’d be happier, though, if that storehouse weren’t so tightly tied to a particular device. As we enter a world of wearables, our devices will increasingly talk directly to servers over the Internet—the cloud, in other words—without the mediation of a smartphone. Smartphones and tablets will be access devices where we can review and analyze this data, but they don’t need to be the central hub.
I can understand why Apple, which makes its money selling mobile devices, would favor a device-centric approach. I’m just worried that it won’t give HealthKit a very long lifespan.
Photo by Shutterstock; screenshot via Apple
