HealthKit Mobility: 9 Gait Metrics

Nine HealthKit identifiers make up the Mobility group: gait figures the system derives from walking, rather than from anything a user starts. Eight are quantity types and one is a category type. Seven of the nine arrived in iOS 14.0 and the other two in iOS 15.0, so the whole group has been in the framework for longer than most of the integrations that ignore it. The HealthKit types introduced in iOS 14 and in iOS 15 list each release's arrivals in full.

What separates this group from the rest of HealthKit is where the numbers come from. These are not measurements a user starts. Four of the eight quantity types define themselves in their own abstracts against ordinary walking: walkingSpeed is the average speed when walking steadily over flat ground, walkingStepLength is the average length of a step under the same conditions, walkingDoubleSupportPercentage is the percentage of time both feet touch the ground while walking steadily over flat ground, and walkingAsymmetryPercentage is the percentage of steps in which one foot moves at a different speed than the other on flat ground. Nothing in those definitions describes a workout, a session, or a device the user has to put on. The subject is walking itself.

stairAscentSpeed and stairDescentSpeed cover the same idea on stairs, one for climbing and one for descending, and they are stored as two distinct identifiers rather than one signed value. sixMinuteWalkTestDistance is the outlier: it stores the distance a user can walk during a six-minute walk test, which is an assessment rather than a passive by-product, and it carries by far the longest discussion text in the group. appleWalkingSteadiness is a percentage measuring the steadiness of the user's gait.

The one category type is appleWalkingSteadinessEvent, which records an incident where the user showed a reduced score for their gait's steadiness. It carries its own dedicated value enum, HKCategoryValueAppleWalkingSteadinessEvent, rather than the generic one, and like every category type it has neither a unit nor an aggregation style.

All eight quantity types state discrete aggregation. Not one is cumulative. That matters more here than it looks, because several of these are percentages and speeds that a naive weekly rollup would happily add together. The correct operations are average, minimum, maximum, and latest, and a gap in the series is an absence rather than a zero. Their unit families are distance, distance per time, distance/time, length, and percentage, which is five labels for three physical dimensions. See the traps below for why that matters.

Nothing in this group has a verified Android counterpart in this site's cross-platform matrix. Every one of the nine is Apple-only until verified, and that is the single most important planning fact about the group: a feature built on walking asymmetry or stair speed has no shipping equivalent on the other platform, so it belongs in an iOS-specific surface rather than in a shared one. Integrating HealthKit covers the authorisation side.

What the group asks of a user is also why it is worth reading. When we compared it with everything else this site covered on September 1, 2026, heart rate variability needed a wrist device the user already owns, sleep staging needed that device worn overnight, and a third-party wearable cloud needed a developer program, an OAuth flow, token rotation and often a paid membership on the user's side. These gait metrics need a phone the user carries and a permission prompt, and the values accumulate whether or not anyone opens your app, so for people who will not wear a chest strap or start a workout they are the only continuously collected data you are likely to get. That is why they matter for products aimed at older adults and for rehab and physical therapy apps. One fall-related type sits outside the group: numberOfTimesFallen, a cumulative count of how many times the user fell, shipped in iOS 8.0 and is filed under Lab and test results, so reading down this group's list will miss it.

One boundary is worth stating plainly. This page describes what each identifier records and how it is stored, and stops there. Apple's abstracts describe gait mechanics; they do not license an app to tell a user what those mechanics mean about them. The moment a product turns these values into a screening result, a risk score, or advice, the question stops being an API question and becomes a regulatory one. Start at FDA regulation for fitness apps before you design that screen, not after.

The identifier list, aggregation styles, unit families, and availability versions here were parsed from Apple's developer documentation on 2026-08-28 and are published in full on the identifier reference.