Why Apps Get Rejected After Adding HealthKit

The rejection email names a clause. The binary started talking to HealthKit last sprint. Those two facts are usually enough.

App Review after HealthKit is not a vibe and it is not FDA. It is a short list of sentences Apple has already written, most of them in section 5.1, one in 2.5.1, plus two Info.plist keys and one entitlement that fail at runtime if you skip them and fail in review if you declare them and do not use them.

This is the table, then the quotes, then the Play Console coda so a cross-platform team does not think the other store is free. The architecture that put HealthKit in the binary in the first place is four authorization models. Capacitor does not get you a lighter 5.1.3 — a web UI inside a native shell is still a native app.

Rejection → clause → fix

2.5.1 — the API is for its intended purpose

Quoted, because the example is the whole point:

Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description. For example, the HomeKit framework should provide home automation services; and HealthKit should be used for health and fitness purposes and integrate with the Health app. [1]

Two tests hide in that sentence. Is the feature health or fitness, or is HealthKit a convenient motion coprocessor for something else? And does the app actually integrate with Health — show up in Sources, write what it claims to write, read what the description says it reads — or did someone add the capability for a spike and leave it?

If you only read, you still integrate: you appear as a source with read access, and the description names the types. If Review replies “please integrate with the Health app” and you already query HealthKit, tell them that — a read-only app shows under Health → Apps with the granted types. Writing placeholder samples to make the row look busier is a 5.1.3(ii) problem. If you never call HealthKit in the shipping binary, strip the capability.

Purpose strings — the sheet is the product

Apple:

This key is required if your app uses APIs that access the someone’s health data. [3]

NSHealthShareUsageDescription for read. NSHealthUpdateUsageDescription for write. Clinical records: NSHealthClinicalHealthRecordsUsageDescription. Missing keys crash on the authorization call, which you will find in TestFlight before Review does.

Guideline 5.1.1(ii):

Ensure your purpose strings clearly and completely describe your use of the data. [1]

The sheet also lists every sample type in the read set. That list is why over-requesting is both a conversion problem and a review problem. 5.1.1(iii) wants data minimization; 5.1.1(iv) wants you not to trick people into consent; 5.1.1(ii) says paid functionality must not be dependent on or require a user to grant access to this data [1]. A paywall behind “Allow” is a 5.1.1 issue before it is a product issue.

Write the string for the user, not for Review, and it tends to pass both: which types, for what in-app behaviour.

If you cannot point at the screen the type feeds, drop it from the read set before you submit.

5.1.2(vi) and 5.1.3(i) — the marketing clauses

These two overlap on HealthKit and both get cited. Quote them in full.

5.1.2(vi):

Data gathered from the HomeKit API, HealthKit, Clinical Health Records API, MovementDisorder APIs, ClassKit or from depth and/or facial mapping tools (e.g. ARKit, Camera APIs, or Photo APIs) may not be used for marketing, advertising or use-based data mining, including by third parties. [1]

5.1.3(i):

Apps may not use or disclose to third parties data gathered in the health, fitness, and medical research context—including from the Clinical Health Records API, HealthKit API, Motion and Fitness, MovementDisorder APIs, or health-related human subject research—for advertising, marketing, or other use-based data mining purposes other than improving health management, or for the purpose of health research, and then only with permission. Apps may, however, use a user’s health or fitness data to provide a benefit directly to that user (such as a reduced insurance premium), provided that the app is submitted by the entity providing the benefit, and the data is not shared with a third party. You must disclose the specific health data that you are collecting from the device. [1]

The last sentence is the listing copy. The rest is why a HealthKit-derived sleep_score_low event in Braze, a lookalike audience, or an ad SDK that “just needs the device graph” is the incident.

The insurance-premium sentence is a narrow carve-out: the app is submitted by the entity providing the benefit, and the data is not shared with a third party. It is not a general licence to personalize lifecycle marketing. We have a guide on using health signals as marketing inputs that is about behavioural context on Sahha’s side of a BAA; it does not override 5.1.3 for HealthKit samples you read in the iOS app. If the pipeline is “HealthKit → our server → a marketing tool,” that is a 5.1.3 fact pattern. Take it to counsel.

2.5.18 separately forbids targeted or behavioural advertising based on sensitive user data such as health/medical data from HealthKit [1]. That is the ads stack, not just the CRM.

5.1.3(ii) — inaccurate writes, and iCloud

Apps must not write false or inaccurate data into HealthKit or any other medical research or health management apps, and may not store personal health information in iCloud. [1]

Two rules.

Do not write guesses into Health. If you estimate sleep from phone motion, that estimate belongs in your UI, not as an HKCategorySample pretending to be a Watch night. Apple’s orthosomnia problem is a product issue; 5.1.3(ii) is the review version of the same honesty.

Do not put PHI in iCloud. That means CloudKit, iCloud documents, iCloud key-value store. It does not say you cannot have a backend. It names iCloud. Teams that enabled CloudKit because it was the default sync for a related non-health feature, then stored samples next to it, are the ones who meet this clause by accident.

Background delivery — fails before Review if you skip it

On iOS 15 and later, enableBackgroundDelivery(for:frequency:withCompletion:) requires the HealthKit Background Delivery capability. Apple: if the app does not have com.apple.developer.healthkit.background-delivery, the method fails with errorAuthorizationDenied [4].

Review will not always be the first to notice. Your sync will. Register observer queries at launch, call the completion handler on every path (including errors), and know that some types are capped at hourly [4]. If you do not call the completion handler, HealthKit backs off; after three failures it stops sending background updates [9]. Call it after you have persisted locally, not after a POST returns — holding it open across the network is how productions go quiet. That looks like “HealthKit is broken” in the field.

If you do not background-sync, do not flip the capability to make the entitlements file look complete. Unused entitlements are their own review conversation.

Privacy Nutrition Label, screenshots, demo account

5.1.1(i) requires a privacy policy in App Store Connect metadata and in the app, covering what you collect, how, all uses, third parties, retention and deletion, and how to revoke [1]. 5.1.3(i) requires you to disclose the specific health data collected from the device.

App Privacy (the Nutrition Label) is where reviewers reconcile the binary with the listing. Types you request, types an SDK requests, and types you listed must match. “Health & Fitness” as a yes/no without the subtypes you actually read is how you get a metadata rejection rather than a 5.1.3 essay.

For review: a demo account that already has HealthKit data, or a reviewer note that says the sandbox has no Watch and here is what empty looks like. HealthKit’s empty read is ambiguous by design. If the reviewer grants permissions and sees zeros, they need to know that is a valid state.

A note that has actually survived this:

HealthKit read access is optional. An empty dashboard after granting Sleep and Steps is a valid state (no Watch paired, or a quiet day). The app does not write samples to Health. Background Delivery is used only for sleep and steps, matching the listing.

Do not send the reviewer into a flow that requires a paired Watch unless the listing says the product needs one.

5.1.1(ix): apps in highly regulated fields including healthcare should be submitted by a legal entity, not an individual developer [1]. If you are actually clinical, that is your account type, not a purpose string.

Human-subjects research is 5.1.3(iii)–(iv): consent elements and an independent ethics board, proof on request [1]. A wellness score is not automatically research. A study protocol in the app probably is.

Play Store, as a coda

Google’s equivalent is a form, not a guideline number.

Play Console → Policy → App content → Health apps declaration. Every app, including those that declare they have no health features. If you use Health Connect, you also declare each data type you read or write and justify it; high-sensitivity types (reproductive health, substance use, clinical vitals, symptoms) get heightened scrutiny [5] [6]. READ_HEALTH_DATA_HISTORY and READ_HEALTH_DATA_IN_BACKGROUND are extra permissions with their own rows [7].

Health Connect’s permission UI opens your privacy policy from a URL you provide. It must be publicly reachable https://, the same policy as Play Console, not a file in the APK [8]. Capacitor apps that skip privacyPolicyUrl fail this in a way that looks like a plugin bug.

Manifest permissions that do not match getSensorStatus / the types you request fail builds or review. That is the Android version of the Nutrition Label mismatch.

What this is not

It is not FDA General Wellness. Review can accept a binary whose website later makes a disease claim. The FDA can ignore an app Review bounced for a purpose string.

It is not HIPAA. Most direct-to-consumer HealthKit apps are not covered entities. 5.1.3 still applies.

It is not a reason to avoid HealthKit. It is the cost of the on-device authorization model. The teams that pass once treat the listing, the plist, the entitlement, the Privacy Label, and the SDK graph as one spec, and they do it before the first requestAuthorization in production.

A health data SDK does not absorb App Review. If Sahha or anyone else is in the binary, their types are your types on the Nutrition Label, and 5.1.3 still names you. What a layer can do is stop you inventing a fifth authorization model. The store is Apple’s.

Before you submit

Do these in order. Review is slower than a plist fix.

1. Diff the read set against the UI. Every type on the sheet has a screen, or it comes out.
2. Write the purpose strings as feature copy, then paste them into Info.plist. Clinical records get their own key.
3. Enable Background Delivery only if you call enableBackgroundDelivery. Flip it the other way around and you have a runtime failure or an unused entitlement.
4. Fill App Privacy from the binary, not from memory, including types an SDK requests.
5. Name the types in the App Store description. 5.1.3(i) asks for specific health data collected from the device.
6. Grep the marketing and ads SDKs for health-derived events. 5.1.2(vi) and 5.1.3(i) do not care that the event is “just for lifecycle.”
7. Confirm nothing health-shaped lands in CloudKit or iCloud Drive.
8. Attach a demo account or a reviewer note that empty HealthKit is a valid state, not a broken build. Do not require a paired Watch unless the listing does.
9. Do not gate paid features on granting HealthKit. 5.1.1(ii) is explicit.
10. On Android, complete the Health apps declaration and put a public https:// privacy policy on the Health Connect permission screen.