HealthKit Permission Builder
240 identifiers and 14documented read-only types · read from Apple’s documentation on 2026-08-28
Pick the HealthKit identifiers your app reads or writes and this returns three things: the Info.plist usage-description keys you actually need, the toShare and toRead sets for requestAuthorization(toShare:read:), and the Health Connect record names for the types verified on both platforms. It refuses to put a type in a write set when Apple's own documentation says the samples are read-only, and it shows you Apple's sentence rather than asking you to take its word for it. Everything runs in your browser.
Type to search all 240 identifiers Apple documents — quantity, category, characteristic and workout activity.
Nothing picked yet. Add a type and the Info.plist keys, the Swift authorization call and the Health Connect record names appear below.
The usage-description strings are placeholders on purpose. App Review reads them, and a generated sentence that does not describe what your app actually does with the data is the version that gets rejected. Copy the keys; write the strings yourself. /tools/permission-builder
The caveat that outlives this page
Generating a correct authorization call is the easy half. The half that breaks products is what happens afterwards: HealthKit does not tell you whether the user granted or denied read access. That is deliberate — reporting it would leak whether a person has health data at all. authorizationStatus(for:) reliably reflects only write and share status; for read types it typically returns .notDetermined even after a grant.
So requestAuthorization succeeding means the sheet was shown, not that read was granted. Never gate your UI on read-authorization status. Run the query and treat an empty result as no data or no permission — the two are indistinguishable, by design. Design the empty state before the happy path.
- How to integrate Apple HealthKit → — the guide these snippets follow, step by step.
- The HealthKit error that never fires → — why an empty read is not a denial, and what to build instead.
Where this output comes from, and where it runs
Everything on this page runs client-side. Your selection never leaves the browser: there is no request to a server, nothing is stored, and no health data is involved at any point — you are picking type names, not data.
The identifier list is Apple’s own, parsed from their developer documentation on 2026-08-28 and published in full at every HealthKit type identifier. The 14 read-only flags come from the same corpus, each carrying the Apple sentence it was derived from; an identifier absent from that list is unknown, not writable, because Apple states writability in prose and silence is not a statement.
Android record names come only from the cross-platform matrix, which is restricted to metrics confirmed against both platforms’ documentation. Where a type has no matrix row, the tool says so rather than guessing a record name. Permission string format and client code for Health Connect are not published here because this site has not verified them.
Swift symbols are emitted only where the integration guide establishes them. HKQuantityType(.case)is the iOS 16+ initializer; the category and characteristic initializers are not established here, so the generator names those picks in a comment instead of inventing a constructor. Verify every signature against Apple’s current documentation before you ship.
A free tool from AIFitnessAPI. Data read from Apple’s published documentation on 2026-08-28; the machine-readable export is on datasets.