Apple Health Is Not an App. It’s Infrastructure.

Photo by Luke Chesser on Unsplash

Most people think of Apple Health as the place where their step count lives. That’s understandable. The icon looks like a heart. The interface shows you graphs. It feels like a dashboard.

It’s not a dashboard. It’s a database with an API layer, a permission model, a local compute strategy, and an interoperability spec. The consumer-facing UI is almost incidental.

Once you see it that way, everything changes.

HealthKit is middleware, not a feature

At the core of Apple Health sits HealthKit, a framework that defines what health data is, how it’s structured, and who gets to touch it.

Every data point has a type. HKQuantityType for measurable values like heart rate or body mass. HKCategoryType for states like sleep stages or menstrual flow. HKCorrelationType for composite readings like blood pressure, which needs systolic and diastolic together to mean anything. HKWorkoutType for activity sessions with their own timeline and metadata.

This taxonomy isn’t arbitrary. It’s an attempt to create a shared language across the entire ecosystem. When your glucose monitor writes a reading and your endocrinologist’s app reads it back, HealthKit is the contract that makes that exchange possible without anyone building a custom integration.

Apps don’t get blanket access. They request permission for specific data types, in specific directions, read or write, and the user approves each one. That granularity matters. It means a sleep tracking app can write sleep data without being able to read your medications. A workout app can log calories without seeing your cycle data.

That’s not a privacy checkbox. That’s an architecture decision that shapes the entire ecosystem built on top of it.

The edge computing bet nobody talks about

Here’s the part that gets almost no attention: your health data doesn’t live in Apple’s cloud. It lives on your device.

HealthKit stores data locally, encrypted when the device is locked, and only syncs to iCloud under end-to-end encryption that Apple explicitly says it cannot access. The processing, the querying, the trend calculations, all of that happens on your phone.

In an industry where almost every competitor’s business model involves centralizing user data on their servers, this is a genuinely unusual choice. It’s expensive. It’s technically harder. And it gives Apple a credible privacy story that nobody else in the space can match, because it’s architectural, not just a policy.

Edge computing applied to health data means that your most sensitive personal information never has to leave your possession to be useful. That’s a different philosophy than “we protect your data on our servers.” It’s “we never have your data to begin with.”

The tradeoff is real: on-device processing limits the complexity of what can be computed, and training models on distributed private data is genuinely hard. But as a competitive position, it’s defensible in a way that promises about cloud security simply aren’t.

The quiet work of normalization

Interoperability between health data sources is a mess. Different devices measure in different units. Different apps define the same concept differently. A “step” from a Garmin watch is not algorithmically identical to a “step” from an iPhone accelerometer. A sleep “efficiency” score from one app shares a name but not a methodology with the same metric from another.

HealthKit imposes standardization on top of that chaos. Units are normalized. Time-series data is stored with consistent timestamps and source metadata. Every reading carries provenance: which device logged it, which app wrote it, when exactly it was recorded.

This sounds boring. It’s actually foundational.

Clinical databases have spent decades building standards for exactly this problem, HL7, FHIR, SNOMED, and they’re still not solved. HealthKit made a narrower bet: standardize the data model for the consumer wearable and app ecosystem, make it strict enough to be useful, and open it up to third parties.

The result is that when Apple Health aggregates data from an Apple Watch, a third-party blood pressure cuff, a glucose monitor, and a manual entry, those data points can sit in the same time-series and be queried together. That’s not nothing. That’s what longitudinal health data actually requires.

How open is open?

Apple has invested real effort in interoperability with the clinical world. The Health Records feature pulls structured data from participating hospitals and health systems using the FHIR standard, putting lab results, immunization records, allergies, and clinical notes alongside your wearable data in a single view.

The ecosystem of third-party apps is large and genuinely functional. Strava, MyFitnessPal, Garmin Connect, and hundreds of others read and write through HealthKit. The permission model makes integration predictable for developers.

But the honest question is where the boundary sits.

HealthKit works beautifully within Apple’s orbit. Outside it, friction multiplies fast. Fitbit doesn’t integrate natively. Samsung Health requires third-party sync bridges. Health Connect on Android is a parallel ecosystem, not a connected one.

The openness is real but bounded. And the boundary maps suspiciously well onto Apple’s competitive interests.

A truly open health data layer would be platform-agnostic. HealthKit is open within a walled garden, which is a different thing. For users who live entirely in Apple’s ecosystem, that distinction is invisible. For anyone who doesn’t, it’s the entire problem.

What’s missing at the infrastructure level

HealthKit is good infrastructure for storing and moving health data. It’s weak infrastructure for understanding it.

There’s no semantic layer. The system knows that your resting heart rate was 62 bpm last Tuesday. It doesn’t know what that means in the context of your training load, your sleep quality, your recent illness, or your age and baseline. The data is structured. The meaning is absent.

Native intelligence is minimal. The trend detection in the Health app is useful but shallow. There’s no reasoning engine that connects data types, surfaces anomalies, or generates hypotheses. That work is entirely delegated to third-party apps, which means the quality of insight you get from Apple Health depends entirely on which apps you’ve installed and authorized.

This is the gap that Health+ is reportedly meant to close. An AI layer that sits on top of HealthKit, reasons across data types, and generates personalized guidance. The architecture supports it. The execution is still ahead.

Whoever controls the infrastructure controls the ecosystem

That’s the strategic reality underneath all of this.

Apple built a data layer that every health and fitness app has to touch if it wants to exist meaningfully on iOS. They defined the types, the permissions model, the storage spec, the sync behavior. Every developer who integrates with HealthKit is building on Apple’s terms.

That’s not cynical. It’s how infrastructure works. AWS defined what cloud compute looks like and every company building on the internet had to adapt. Apple defined what personal health data looks like on mobile and every health app developer had to adapt.

The question going forward is whether that infrastructure earns its position by being genuinely useful, trustworthy, and open enough to support an ecosystem, or whether it calcifies into a moat that benefits Apple more than it benefits the people whose data it holds.

Right now it’s both, and the balance is still being negotiated.