Skip to content
AF
HealthKit reference

HealthKit Characteristic Types

6 identifiers · read from Apple’s documentation on 2026-08-28

6 HealthKit characteristic identifiers, with no aggregation style, no unit family and no samples. They are read-once identity facts, not a time series.

There are 6 characteristic type identifiers, and they are the odd family out in HealthKit. Not one of them has an aggregation style. Not one has a unit family. The group's list of unit families is empty, and the dataset records no value enum for any of the six. Those blanks are not missing research. They are what a characteristic is: a fact about the person, not a measurement of the person.

The six are activityMoveMode, biologicalSex, bloodType, dateOfBirth, fitzpatrickSkinType and wheelchairUse. Apple's wording for each is worth taking literally, because every abstract in the group says "the user's". The user's sex, the user's blood type, the user's date of birth, the user's skin type, the user's use of a wheelchair, the user's activity mode. These are answers somebody gave, not readings a sensor produced, and answers can be revised or left blank.

The practical consequence is that there is no time series here. Nothing in this group has a value that repeats over a date range, so there is nothing to chart, nothing to roll up by day, and no day boundary question to solve. In your own schema these belong on the user record, beside the account, and not in the samples table with everything else you pull out of HealthKit. Any ingestion code that assumes every HealthKit identifier produces rows with a start date, an end date, a value and a unit will need a separate path for these six. If you are wiring the read side for the first time, the HealthKit integration guide covers where they sit relative to sample queries.

By availability, three of them are original: biologicalSex, bloodType and dateOfBirth all date to iOS 8.0. fitzpatrickSkinType followed in iOS 9.0, wheelchairUse in iOS 10.0, and activityMoveMode in iOS 14.0. The arrival order is a fair guide to what each one was added for, and the two later additions are also the two most likely to change during the life of an account. A date of birth is fixed. A blood type is not something a person edits often. Wheelchair use and activity mode are current circumstances, and a value you cached at first launch can quietly stop being true.

Documentation is thinnest exactly where you would want it thickest. Three of the six, activityMoveMode, dateOfBirth and wheelchairUse, carry zero words of discussion in Apple's docs. The other three carry 7 words each. For activityMoveMode in particular, that leaves you with the abstract, "a characteristic identifier for the user's activity mode", and no documented list of what the modes are. The dataset does not record a value enum for it, or for any of the others, so if you need the valid cases you will be reading them out of the framework rather than out of a reference table.

None of the six has a verified Android counterpart in the cross-platform matrix, which is unsurprising: identity facts tend to live in your own account system rather than in a health store, and that is usually the right place for them. Read from HealthKit to prefill, keep your own copy as the source of truth, and let the user correct it.

Two more things worth planning for. First, reading a characteristic still needs the user's permission, so a blank field in your UI can mean either that nobody ever filled the value in or that your request was never granted. If reads come back empty, authorization denied is the first thing to rule out, and the empty state is worth designing before the happy path. Second, if you feed age or sex into an estimate, be deliberate about it, because those inputs change a displayed number without the user seeing why. How fitness apps estimate calories covers where they land.

The names, abstracts and availability versions above come from Apple's developer documentation as parsed on 2026-08-28; the full set of identifiers, this group included, is listed in the complete identifier list.

The 6 identifiers in characteristics

Every field is joined from Apple’s documentation. Aggregation style and unit family are the two Apple states only in prose — where its wording does not state one, this table says so rather than guessing. Android names appear only where the mapping is verified on both platforms.

IdentifierWhat it isAggregateUnitiOSAndroid
activityMoveModeHKCharacteristicTypeIdentifierActivityMoveModeA characteristic identifier for the user’s activity mode.14.0not verified
biologicalSexHKCharacteristicTypeIdentifierBiologicalSexA characteristic type identifier for the user’s sex.8.0not verified
bloodTypeHKCharacteristicTypeIdentifierBloodTypeA characteristic type identifier for the user’s blood type.8.0not verified
dateOfBirthHKCharacteristicTypeIdentifierDateOfBirthA characteristic type identifier for the user’s date of birth.8.0not verified
fitzpatrickSkinTypeHKCharacteristicTypeIdentifierFitzpatrickSkinTypeA characteristic type identifier for the user’s skin type.9.0not verified
wheelchairUseHKCharacteristicTypeIdentifierWheelchairUseA characteristic identifier for the user’s use of a wheelchair.10.0not verified

What will bite you

Three of the six document nothing beyond the abstract. activityMoveMode, dateOfBirth and wheelchairUse carry zero words of discussion; the remaining three carry 7 words each. For activityMoveMode that means one sentence naming the concept and no documented list of modes, so any switch statement you write against it is built on what you found by inspection, not on what Apple stated. Comment it accordingly.

No value enum is recorded for any of them. Sex, blood type, skin type and activity mode are all enumerated concepts, but the dataset holds no enum name for a single characteristic. Do not expect a reference table to hand you the valid cases. Read them from the framework, and handle the case your version of the enum does not know about.

They break generic sample pipelines. Because there is no aggregation style, no unit family and no date range, code written on the assumption that every identifier yields timestamped numeric rows will either crash or, worse, insert a nonsense row with a fabricated unit. Give characteristics their own read path and their own storage, on the user record rather than the samples table.

A cached characteristic goes stale silently. Wheelchair use and activity mode describe a person's current circumstances, and any of these values can be changed in Health after your first read. If you read once at onboarding and never again, your copy drifts and nothing tells you. Re-read on a schedule you choose deliberately, and let the user override what you stored.

Questions

What is a HealthKit characteristic type?
One of 6 identifiers describing a fact about the person rather than a measurement of them: activityMoveMode, biologicalSex, bloodType, dateOfBirth, fitzpatrickSkinType and wheelchairUse. None carries an aggregation style, a unit family or a value enum in the dataset, because a characteristic is a single stored answer and not a stream of samples.
Why is there no history for a HealthKit characteristic?
Because a characteristic has no date range attached to its value. There is no sample to timestamp, so there is nothing to chart, nothing to total by day and no day boundary to decide. Store the value on the user record in your own database rather than in whatever table holds your HealthKit samples.
Which HealthKit characteristics can change?
Any of the values can be edited, but wheelchairUse, added in iOS 10.0, and activityMoveMode, added in iOS 14.0, describe current circumstances rather than fixed facts, so they are the ones most likely to move. A value you read once at onboarding and cached can go stale without any signal to your app.

All 6 identifiers above were read from Apple’s documentation on 2026-08-28. See the full 240-identifier table for every group at once, or the datasets for the same data as JSON and CSV. Apple’s abstracts are quoted for identification; the grouping, the aggregation split and the cross-platform mapping are AIFitnessAPI’s.

← All HealthKit groups