Apple App Store Health Data Rules: What You Need to Ship a HealthKit App

Apple lets you build health apps and use HealthKit, but only if you follow a specific set of privacy rules baked into the App Store Review Guidelines. The short version: you must publish a privacy policy, you must never use health data for advertising or data-mining, you must not sell it, and if your app has accounts you must let users delete theirs from inside the app. These are Apple's contractual rules, not law, and they sit on top of any legal obligations you have (GDPR, state consumer-health laws) rather than replacing them. This page is general engineering guidance, not legal advice — confirm the current guideline text before you submit, because Apple renumbers sections often.

Does this apply to you?

If your iOS app touches health or fitness data, yes. The rules bite hardest on apps that use these Apple frameworks:

• HealthKit (steps, heart rate, workouts, sleep, and everything else in the Health app)
• Clinical Health Records API
• Motion & Fitness and the MovementDisorder APIs

Data from these sources gets the strictest treatment. But even a fitness app that never touches HealthKit — say, one that only stores workouts you type in — still needs a privacy policy and still faces the general privacy rules in Section 5.1 of the guidelines. There is essentially no version of "health app" that escapes these requirements.

One more scoping point: Apple treats healthcare as a "highly regulated" field, so your app generally must be submitted by a legal entity, not an individual developer account. Verify the current wording, since this sits in the 5.1.1 area and Apple moves it around.

What Apple's rules actually require

The subsection numbers below reflect the guideline structure as of mid-2026. Apple restructures Section 5.1 regularly, so treat every number as approximate and verify the live subsection before you rely on it. The rules themselves are stable even when the numbering shifts.

The narrow "direct benefit" carve-out

There is one limited exception to the no-sharing rule: an app may share health data for a direct user benefit — the classic example is a reduced insurance premium — but only if the app is submitted by the benefit provider itself AND the data is not shared with any other third party. Do not read this as a general "you can share health data if the user gets something." It is deliberately narrow and conditional.

If you run research

Human-subject research raises the bar. Under guideline 5.1.3 (verify current subsection), you need:

• Informed consent covering the nature, purpose, and duration of the study; procedures, risks, and benefits; confidentiality and any third-party sharing; a contact; and how to withdraw. Minors need parent or guardian consent.
• Approval from an independent ethics review board, which Apple can ask you to prove on request.

App Privacy labels and privacy manifests

Two more Apple requirements live outside the review guidelines proper:

• App Privacy "nutrition labels." The App Store's App Privacy section (introduced in 2020) requires you to disclose all of your data-collection and data-use practices — including those of any third-party SDKs you embed. These labels must match what your app actually does.
• Privacy manifests and required-reason APIs. [Verify — this area changes.] Since around May 1, 2024, apps and third-party SDKs have been required to declare the data they collect and justify their use of certain "required-reason" APIs in a privacy manifest, with signed SDKs, or App Store Connect can reject the build. Confirm the current requirements and deadlines before you submit.

What this means for a fitness app

• Ship a privacy policy first. It's mandatory for HealthKit apps and cheap to get right. Cover collection, use, sharing, retention, and deletion. See the health app privacy policy guide for what to include.
• Wall off health data from your ad stack. Don't pipe HealthKit data — or anything derived from it — into analytics or advertising SDKs. This is a hard prohibition, not a preference.
• Build in-app account deletion before launch. Retrofitting it later is painful. Deletion has to reach the associated data too, not just the login row.
• Don't lean on iCloud for health data. Keep personal health information out of iCloud storage; verify the current guideline wording as you architect sync.
• Remember Apple's rules are not the whole picture. An App Store approval does not make you GDPR- or state-law-compliant. A HealthKit permission prompt is an OS access control, not a legal consent. See health data user consent for the distinction.

For the implementation details of requesting HealthKit permissions and handling the authorization sheet, see the HealthKit integration guide. Building for Android too? The equivalent rules live on the Google Play health data policy page — they overlap heavily but differ in the specifics.

A note on limits

Apple's guidelines are contractual App Store rules, enforced through app review — they are not a substitute for HIPAA, GDPR, or state consumer-health laws, and passing review does not mean you've met those legal obligations. Apple also reorganizes and renumbers Section 5.1 frequently, so the exact subsection letters here may already have shifted; always read the live guideline text at the time you submit. For anything with legal consequences, confirm your obligations with a qualified professional.