Generate your stack
Four questions — what you are building, which platforms ship, how much wearable data you need, and whether the team is optimising for speed or control — and you get the HealthKit types that category touches and the APIs that survive those answers, each one carrying the reason it survived. The reasons are fields, not opinions: how the product bills developers, what every end user must own, what approval gates your launch, and our published rough judgement of the integration work.
Question 1 of 4
What are you building?
What this will not do
It will not rank. There is no score behind the ordering — products are filtered by your answers and then sorted by the same fields the comparison tool prints, with the sort key stated on screen so you can disagree with it. The one judgement in the model, integration effort, is labelled as ours everywhere it appears, because it is the only field in the directory that is not backed by a published sentence.
It will also not fill an empty result. Some combinations exclude everything a category lists — a web-and-backend-only product that wants platform-store data has nowhere to read it from, because both stores are on-device — and the tool says so instead of offering a consolation pick. When that happens, the exclusions are the answer: loosen the constraint you can live with, or plan to build that layer.
For a whole-stack cost shape at your user count, use the cost planner. For a starting recommendation before you know the category, the picker asks three broader questions. For the full type reference behind the table, every HealthKit type identifier lists all of them with the platform each was introduced on.