HealthKit: 127 of 240 Types Are iOS 8.0

HealthKit exposes 240 type identifiers. 127 of them shipped in iOS 8.0, and every release since has added a handful on top.

Update, October 2, 2026. When this site re-read Apple's documentation on October 2, 2026, the list had grown to 241: iOS 27.0 added heartRateVariabilityRMSSD, which Apple documents with a declaration and nothing else, and bleedingAfterMenopause and menopausalState are no longer marked beta. 127 still date from iOS 8.0. The figures in this post are the 240 identifiers read on August 28, 2026; every HealthKit type identifier carries the current read.

That means the shape of the API was decided in one go, at the beginning, and almost everything after is a long tail. If you are planning an integration around "what Apple adds next", you are planning around the small end of the distribution.

The counts here come from this site's own HealthKit identifier dataset, parsed from Apple's developer documentation on 2026-08-28 and republished as an open dataset on /datasets.

The full version histogram#

The version strings are Apple's, including the jump from 18.0 to 26.2. We record what the documentation says rather than normalising it.

Read down that column and the pattern is obvious. After the opening 127, the biggest single release is 20 identifiers in iOS 10.0. Then 17 in iOS 16.0, 14 in iOS 14.0, 10 each in iOS 9.0 and iOS 18.0. Everything else is single digits, and six releases contributed one or two identifiers apiece.

The bursts have themes#

For iOS 16.0 and later the dataset records which identifiers arrived in which release, and the clusters are legible.

iOS 16.0 brought the running-form set (runningGroundContactTime, runningPower, runningSpeed, runningStrideLength, runningVerticalOscillation), underwaterDepth and waterTemperature, appleSleepingWristTemperature, atrialFibrillationBurden, heartRateRecoveryOneMinute, environmentalSoundReduction, a block of menstrual cycle deviation flags (infrequentMenstrualCycles, irregularMenstrualCycles, persistentIntermenstrualBleeding, prolongedMenstrualPeriods), plus swimBikeRun and transition.

iOS 17.0 is almost entirely cycling: cyclingCadence, cyclingFunctionalThresholdPower, cyclingPower and cyclingSpeed, alongside physicalEffort, timeInDaylight and underwaterDiving.

iOS 18.0 is rowing, paddling, skating and cross-country skiing (crossCountrySkiingSpeed, distanceCrossCountrySkiing, distancePaddleSports, distanceRowing, distanceSkatingSports, paddleSportsSpeed, rowingSpeed) plus appleSleepingBreathingDisturbances, estimatedWorkoutEffortScore and workoutEffortScore.

The newest entries are thin. iOS 26.2 added hypertensionEvent. iOS 27.0 added bleedingAfterMenopause and menopausalState, and those two are the only identifiers in the dataset flagged as in beta on some platform.

Reading intent into that clustering is inference, not something Apple states. But a release that adds four cycling power and speed metrics at once is not responding to a documentation request. If you want to guess where the sensor work is going, the histogram is a better signal than the keynote.

Four are deprecated, none removed#

Correction, October 2, 2026. This section was headed "Nothing is marked deprecated" and said that none of the 240 identifiers carried a deprecation marker. Four did. Apple records a deprecation as a deprecatedAt version on each platform entry and leaves a separate deprecated flag false, and the generator behind this post read only the flag. All four were deprecated in iOS 10.0 to 14.0, releases older than the newest ones this post covers, so the claim was wrong when it was published. The section, the description and the FAQ now say so, and the corrections log records the change.

Four of the 240 identifiers are deprecated in Apple's availability data: the workout activity types dance (deprecated in iOS 14.0), danceInspiredTraining (iOS 10.0) and mixedMetabolicCardioTraining (iOS 11.0), and the category type audioExposureEvent (iOS 14.0). Apple files the first three under a group called "Deprecated activity types". audioExposureEvent sits in its Hearing group, and Apple names environmentalAudioExposureEvent as its new name. Each comes with a note on Apple's page saying what to use instead.

None of the four has been removed. A snapshot taken on one date cannot prove Apple has never withdrawn anything, but what this one shows is that a deprecated identifier stays in the catalogue beside its replacement, and the list you have to handle only grows. Any switch statement, database column mapping or analytics dimension you build over these identifiers is a structure that gets longer every year and never gets shorter.

Design for that. A default case that silently drops an unrecognised identifier will start dropping real user data the first autumn after you ship, and nobody will report it because the app will not crash. Store the raw identifier string alongside whatever you map it to, so that a type you did not know about on release day is still recoverable later.

The platform axis does not vary#

Every one of the 240 identifiers is listed as available on all six platforms Apple names: iOS, iPadOS, Mac Catalyst, macOS, visionOS and watchOS. None is watchOS-only. None is iOS-only.

This surprises people who assume the Watch has a private set of types. It does not. What varies is the OS version, which is why the histogram above is the table that matters and a platform matrix would be a single filled-in block.

Availability of a type is a separate question from whether any data exists behind it. Our cross-platform matrix makes the same point about blood oxygen: the type being present says nothing about whether a device on the user's wrist is writing to it. If you are shipping a watch target, the HealthKit on Apple Watch notes cover where the read actually happens.

Compare that with everything else you integrate#

Four deprecations and no removals is worth saying out loud because almost nothing else in this space behaves that way. Our dated changes list tracks 13 ecosystem events, 6 of them confirmed and 7 only reported, and most of them are subtractions rather than additions.

Google's own documentation states that the Fit APIs will be supported until the end of 2026, and that one is confirmed. The Fitbit Web API turndown is reported, not confirmed: third-party guides name a specific day, we could not verify one on a first-party page, and tokens are reported not to transfer, so every user re-consents. Oura deprecated personal access tokens in December 2025, which is confirmed. Strava tightened its developer program in 2024, also confirmed.

Set that against a platform API whose identifier list only ever gets longer. HealthKit is a low-maintenance dependency in the one dimension that usually hurts, which is the dimension where somebody else decides your deadline. A new identifier in iOS 27.0 is never a breaking change for you. It is an option you can exercise whenever you get to it.

That changes where the engineering budget should go. With a vendor API, a meaningful share of the work is migration insurance: watching announcements, keeping a dual-read path, planning re-consent. With HealthKit the same hours are better spent on what the individual types actually mean, because that is where the real ambiguity sits and no deadline will force you to deal with it.

What to do with this#

Generate your identifier mapping instead of typing it. A hand-maintained enum of 240 cases is a file nobody re-reads, and the additions arrive on Apple's schedule rather than yours. We regenerate ours from Apple's documentation JSON and fail the build when the parse comes up short, which is described on /methodology.

Guard the newest types behind availability checks and write the fallback path first. hypertensionEvent and the two iOS 27.0 identifiers will read as absent on most installed devices for a long time, and "absent" is the case your UI has to be honest about rather than the exception.

Do not assume an old identifier is well specified just because it is old. The 127 that shipped in iOS 8.0 include some of the thinnest documentation in the whole set, which is the subject of a separate count.

And when you are scoping an integration, start from the group you actually need rather than the total. The integration guide walks the permission model, and if you are also targeting Android, the HealthKit versus Health Connect comparison is where the type counts stop matching up.