Health in iOS 8: Explained

Health is the name for a new, built-in Apple app coming with iOS 8. It serves as both a repository for all the health-related data accumulated by your iPhone, your apps, and your accessories, and a dashboard to help you make better, more visual sense of it — a front-end for your quantified life. To facilitate all this, Apple is providing the HealthKit framework to developers and manufacturers. But how does it all work?

Health goals

The iPhone, primarily due to its highly mobile form factor and constant connectivity, has become a platform upon which a plethora of health and fitness apps and accessories are built. There's an Apple M7 motion coprocessor in the iPhone 5s (as well as the iPad Air and Retina iPad mini) to help collect activity data in as power-efficient a way as possible, but there are also a half-dozen or more fitness bands, as well as scales, blood pressure readers, blood sugar readers, sleep trackers, and more. There's even a Bluetooth fork.

In addition to apps that collect and track data, there are apps that let people manually enter data, like what they ate or how they felt at a specific time. There are apps that perform statistical analysis and provide graphical reports on data to help you better visualize specific metrics. There are apps from healthcare providers that let you send your information back to them to keep your records up-to-date.

Yet all that data about activity and sleep, diet and nutrition, mood and medication, vital signs and test results, all remains locked into the silos of all those individual apps.

Apple's Health app is designed to bring all that data together and to put it all in one, convenient, easy to refer to place. The hope is that the whole is more valuable than the sum of the silos, both for the human being using it, and for any medical professionals we expressly choose to be involved.

Health app

Rumor has it Health was originally conceptualized as HealthBook, a card-based interface similar to PassBook. However, the sheer number of sources that ultimately got included required a shift to a more scalable, list-based interface. So, Health.

Health is the front-end for HealthKit (see below). It includes a dashboard section, where you can place the readouts most important to you. For example, steps if you're working with a fitness tracker, or blood sugar, if you're diabetic. From here you can quickly and easily tab through day, week, month, and year views.

There's a Health Data section that lets you see everything, including All, Body Measurements, Fitness, Me, Nutrition, Results, Sleep, and Vitals. Body measurements include fat percentage, mass index, height, lean body mass, and weight. Fitness includes active calories, distance, flights climbed, NikeFuel, resting calories, and steps. Me lets you enter birthdate, biological sex, and blood type. Nutrition stores a long list of food, mineral, and vitamin types from biotin to zinc. Results stores a wide variety of test results from blood alcohol content to peripheral perfusion index. Vitals can keep track of blood pressure, body temperature, heart rate, and respiratory rate.

Each shows its graphical widget, the ability to show data, add data, share data, and a toggle to put them on or take them off the dashboard. If you want to change up what's in your dashboard, or want to drill down into data that you don't need often, but do need at that moment.

The Sources section lists the apps and accessories that are currently connected to Health via HealthKit. Over time you might grant permission for more and more apps and accessories to access your data, and it's helpful if there's a place where you can review all of that and decide what, if any, cleanup is needed.

The Medical ID section lets you create a Lock screen card that shows your birthdate, medical conditions, medical notes, allergies and reactions, medications, contacts, blood type, organ donor information, weight, and/or height. None of this is included in health data or shared with other apps, but will be presented to first responders who might need it to properly treat you in case of emergency.

It can be accessed when your iPhone is locked by tapping Emergency, then Medical ID. And yes, there are some privacy implications to making that information accessible from the Lock screen, but just like a Medicalert bracelet, each of us will have to weigh that against the risks and benefits, depending on our own, personal health situation.

HealthKit for developers

The HealthKit application programming interface (API) lets developers create, save, and ask for health and fitness data. The idea, again, is to have a single place where all developers can contribute towards a composite health profile, so that we can have a better, more complete, more holistic view of their health and fitness.

HealthKit is built into the Capabilities pane in Xcode, just like Game Center and Passbook. To help developers and users alike, Apple provides tools within HealthKit to make working with health and fitness data easier. For example, HKUnit can handle both simple and complex conversions between things like the metric system used in the vast majority of the world, and the imperial system used in the U.S. (and, of course, those who still measure their weight in stones in England...). There's also HKObjectType which can store everything from steps to blood pressure to respiratory rate to body temperature to vitamin levels to oxygen saturation to NikeFuel points, and much, much more.

All data stored in HealthKit is a subclass of HKObject, every one has a UUID that persists, and each keeps track of its source, be it an app or accessory. All data is also immutable, since going back in time and changing health or fitness data isn't the preferred methodology.

So, for example, a developer can create an HKObject to record something like body temperature, what the temperature was and when (either exactly for a moment in time or an average over a short period of time), and that it came from an ear thermometer.

To save or query for data from HealthKit, developers create an HKHealthStore. Saving data is straightforward. Developers create it and save it to their store. Querying for data has more options.

Developers can query both data they created and data already stored in HealthKit. However, to query data already stored in HealthKit, they have to get the user's permission first.

HKHealthKit can be directly queried for characteristic data like date of birth and blood type, that don't change over time. HKQuery is more heavy duty. With it, developers can set limits and sort orders, observe for changes in the database, and handle "anchors" (last pieces of data seen).

In addition to objects, developers can ask for statistics with HKStatistics. It includes sum, min, max, and average, and developers can get stats for all data or just for a particular source (app or accessory). Discreet types like height, weight, or blood pressure can return min, max, and average stats. Cumulative types like step count or calories burned can return sum.

To mitigate against calculations being "expensive" (consuming processor resources), HealthKit has developers tell them what they want ahead of time by specifying the type and stat. To mitigate against conflicting or duplicate sources, HealthKit will take the source preferred by the user. Developers, however, can also separate out the sources and do their own merges.

To keep things efficient, HKStatisticsCollection can be used to query for multiple statistics objects, split up into time "intervals". So, a developer could pull steps for every day during the last week and graph them.

All this means Apple has made it easy for developers to store health and fitness data in HealthKit, retrieve it, combine it with other data in HealthKit, and present it in an understandable manner for users.

To get started with HealthKit, Apple has provided information for app developers and accessory manufacturers, including WWDC session videos and sample fitness tracker code.

Health partners

On their own both Health and HealthKit are ambitious and impressive, but Apple has even higher goals in mind for both. Apple is hoping to revolutionize the healthcare industry.

They're partnering with the Mayo Clinic, for example, to integrate with HealthKit so, for example, a patient's blood pressure reading is automatically compared with expectations and, if anything is amiss, their doctor is immediately alerted for follow up.

Apple is also partnering with Epic Systems, which powers hospitals serving hundreds of millions of Americans, so that patients at many major institutions can use Health to faster and more conveniently share their information with their doctors.


Health and HeathKit can make it incredibly convenient to store, retrieve, sync, and share health and fitness information. But as we all know, convenience is in perpetual conflict with security and privacy. A place where all of our data, from different apps and accessories, can get aggregated together and not only presented back to us, but to other apps and shared with healthcare professionals means the underlying system needs to be privacy-first.

It looks like that's exactly what Apple is doing with Health and HealthKit. Before an app can access any data in HealthKit it needs to get express permission. Likewise, before any data can be shared, we need to be the ones who initiate the sharing.

Because health data is incredibly sensitive, Apple goes above and beyond the usual permission system to allow us to authorize or deny access per object type. So, if an app only needs step data, we can only authorize step data and not give it access to anything else.

Read and write permissions are also kept separate per object type. That means we can let a step tracker save data to HealthKit, but not read any data saved there by other apps.

To manage all this, Apple is using authorization sheets — I know, right? — which, instead of a simple popup, provides granular yes/no toggles for each type of data sourced and shared.

Apple also won't let developers know if a specific type of information has been blocked, because that knowledge in and of itself can compromise privacy (i.e. blocking blood sugar might betray diabetes).

We'll have to wait until Health and HealthKit ship, and people test the system in the real world, but Apple's priorities seem well placed.

iPads in the waiting room

Health and HealthKit are currently iPhone only and aren't scheduled to ship as part of iOS 8 for the iPad. Hopefully that'll change in the near future. Some people, including the elderly and those with high level medical needs, might not have an iPhone but might have an iPad.

Passbook, introduced in iOS 6, has thus far remained iPhone only, and maybe that makes sense for a mobile payment system. Health, however, feels like it has a lot to offer iPad customers as well.

Bottom line

Health is best thought of like Passbook, which collects all your tickets and cards, or Photos, which holds all your pictures and videos, or, perhaps, or iCloud Drive which stores and shares all your files and documents. Health presents all the health and fitness data stored in HealthKit in one convenient, centralized location, and in a way that's easy to see and understand.

It remains to be seen whether the general public embraces Health, or if they'd be happier with an iPhone that spewed cheeseburgers from the Lightning port. However, I'm optimistic that Apple's optimistic. Worst case, Health being there, on the Home screen, with its cheery heart icon, will encourage people to think more about health and fitness. Best case, as any one element becomes important, the system itself will make it easy to add other elements in. And there's nothing better than virtuous cause becoming a virtuous cycle.

iOS 8 ships this fall. What do you think of Health and HealthKit, and will you be using them?

More of iOS 8: Explained

Rene Ritchie

Rene Ritchie is one of the most respected Apple analysts in the business, reaching a combined audience of over 40 million readers a month. His YouTube channel, Vector, has over 90 thousand subscribers and 14 million views and his podcasts, including Debug, have been downloaded over 20 million times. He also regularly co-hosts MacBreak Weekly for the TWiT network and co-hosted CES Live! and Talk Mobile. Based in Montreal, Rene is a former director of product marketing, web developer, and graphic designer. He's authored several books and appeared on numerous television and radio segments to discuss Apple and the technology industry. When not working, he likes to cook, grapple, and spend time with his friends and family.