Why HealthKit-Enabled Clinic Apps Get Rejected by Apple — and How to Avoid It

A rejection email from App Review rarely explains the actual problem. It cites a guideline number, maybe a sentence of boilerplate, and leaves the team guessing which line of code or which screen caused it. For clinic apps that read from or write to HealthKit, this is a predictable, recurring cost — the same handful of clauses catch teams over and over, because the mistakes are structural, not accidental.

We've taken HealthKit-integrated patient apps through App Review more than once, and the pattern holds: almost every rejection maps cleanly onto one of a short list of clauses. An iOS team that already knows Apple's health-app review quirks can usually tell you before submission which of these a given build will trip. This post is that map, plus the checklist we run before every submission.

None of this replaces reading the guidelines yourself, and none of it is legal or regulatory advice for whether your app needs FDA clearance — it's an engineering map of where HealthKit submissions actually fail.

Why does Apple scrutinize HealthKit apps harder than other apps?

HealthKit sits at the intersection of App Review and health-data privacy. A photo-editing app that mishandles data embarrasses a user; a clinic app that mishandles step counts, heart-rate samples or medication logs touches something Apple treats as inherently higher-risk, regardless of how small your feature actually is. That's why HealthKit apps get a more literal, more suspicious reading of the App Store Review Guidelines than most categories: reviewers are primed to look for the data flowing somewhere it shouldn't.

The purpose-string trap (clause 2.5.1 and the usage description)

Every app that requests HealthKit access must supply NSHealthShareUsageDescription and, if it writes data, NSHealthUpdateUsageDescription — the strings iOS shows the user in the permission prompt. Reviewers read these literally against guideline 2.5.1, which requires apps to use APIs for their intended purpose and to be transparent about why they're asked for.

A vague string like "to improve your health experience" gets bounced, because it doesn't tell the user — or the reviewer — what the app actually does with the data. A string like "to show your resting heart-rate trend alongside your clinician's notes in your care timeline" survives, because it names the feature and the data type together. Write the purpose string for the specific screen that uses it, not for the app as a whole.

Requesting data types you don't actually use (the #1 rejection reason)

The single most common HealthKit rejection isn't a privacy violation — it's scope creep. A team wires up a broad HealthKit read request during development (steps, sleep, heart rate, blood glucose, reproductive health) and never trims it back once only two of those types ship in the actual feature set. Reviewers compare your requested data types against what the UI visibly does with them, and an unused request is an easy, mechanical rejection: there's no feature to point to that justifies it.

The fix is boring and effective: before every submission, audit the HealthKit entitlement list against the screens that are actually live in the build, and remove anything the user can't see used somewhere.

Data accuracy claims — what you must be able to prove

If your app displays or acts on a derived health metric — a risk score, a trend line, an adherence percentage — Apple expects you to be able to explain the methodology behind it, not just display a confident-looking number. This matters more for clinic-facing apps than consumer fitness apps, because the audience is more likely to act on what the screen says. If a reviewer (or later, a clinician) asks "where does this number come from," you need an answer that isn't "the algorithm decided."

Keep a short internal note — even a paragraph — on how each derived metric is calculated and from which HealthKit sample types. It costs nothing to write and it's the difference between a quick clarification reply to App Review and a drawn-out back-and-forth.

Can you use health data for marketing or analytics? (clause 5.1.3(ii))

No. Guideline 5.1.3(ii) is explicit: health data obtained through HealthKit cannot be used for advertising, marketing, or any purpose beyond the health-management feature the user granted it for — including third-party analytics SDKs that weren't built with this restriction in mind. It also can't be stored in iCloud as part of a general backup; HealthKit has its own encrypted, on-device-first storage model for a reason.

In practice, this means auditing which SDKs in your app can see HealthKit values before they're even written to disk. A generic analytics or crash-reporting SDK that happens to log view-model state can inadvertently capture a heart-rate reading. That's a 5.1.3(ii) violation even if nobody intended it, and it's one of the harder categories to catch without a deliberate audit.

Background delivery and HealthKit capabilities — the pitfall reviewers catch early

Apps that use HealthKit's background delivery to refresh data without the user opening the app need the matching capability declared in the project and a clear reason for it in the purpose string. Teams sometimes enable background delivery during development to make testing easier, ship it accidentally, and get flagged before a human reviewer even looks at the UI — automated checks against the entitlement file catch mismatches between declared capabilities and actual usage patterns.

Before submission, verify the background delivery entitlement is only present if a real feature depends on it, and that the feature is demonstrable to a reviewer without requiring hours of real-world data accumulation.

Privacy Nutrition Label, screenshots, and demo accounts

Beyond the binary, App Review checks three things that teams routinely under-prepare: the Privacy Nutrition Label (does it list health data accurately, matching what the app actually collects — not a generic template copied from another app), the screenshots (do they show real, representative use of the HealthKit feature rather than placeholder data), and the reviewer demo account.

A demo account with no HealthKit data seeded is one of the most common self-inflicted delays: the reviewer logs in, sees an empty state, and can't verify the feature the app claims to have. Seed the demo account with realistic sample data before every submission — don't make the reviewer guess what the feature is supposed to look like.

Is this a wellness feature or a regulated medical app?

There's a meaningful line between "shows the user their own step count" (wellness) and "tells the user to adjust a medication dose based on a reading" (a regulated medical function). Apps that drift from the first into the second — often gradually, as a team adds "helpful" interpretive features — change their own regulatory posture without anyone deciding that on purpose. Apple's review doesn't make this determination for you, but it does notice interpretive or diagnostic language in your copy and UI, and it will ask harder questions once it does.

If your roadmap includes anything that interprets a HealthKit reading rather than just displaying it — a risk flag, a recommendation, an alert — have that conversation with your compliance lead before it ships, not after a reviewer asks whether you're classified as a medical device.

HIPAA doesn't stop at your backend — it reaches into the iOS app

Teams often design HIPAA controls around the server — access logging, encryption at rest, audit trails — and treat the iOS client as a thin, stateless window onto that backend. HealthKit data doesn't cooperate with that model. It's cached locally by the OS, it can be fetched in the background while the app is closed, and it shows up in places teams forget to check: debug logs that print model objects, crash reports that serialize view state, and screen recordings captured during QA or a support call.

A HIPAA-aware HealthKit integration treats the device as part of the compliance boundary, not outside it: scrub PHI from logging before a build ships, disable screen recording on screens that render clinical values, and confirm your crash-reporting SDK's data-scrubbing rules actually catch HealthKit-derived fields. This is exactly the kind of cross-cutting review YuSMP Group's iOS development team builds into the development process from day one, rather than retrofitting before a submission deadline.

Clause	What trips teams up	The fix
2.5.1 — purpose strings	Generic usage description that doesn't name the feature	Write one sentence naming the exact screen and data type
Unused data-type scope	Requesting more HealthKit types than the shipped UI uses	Audit entitlements against live screens before every submission
5.1.3(ii) — marketing/analytics use	A third-party SDK can see HealthKit values before they're scrubbed	Audit every SDK's data path for health-sample exposure
Background delivery capability	Entitlement declared without a demonstrable feature behind it	Remove the entitlement unless a shipped feature needs it

Pre-submission checklist

1. Audit every requested HealthKit type against the screens that actually use it in the shipped build, and remove the rest.
2. Write purpose strings that name the specific feature and data type, not a generic "improve your health" phrase.
3. Confirm no analytics, crash-reporting, or ad SDK can log a raw HealthKit sample before it's scrubbed.
4. Verify the Privacy Nutrition Label matches the real data flows in this build, not a template from a previous app.
5. Test the background delivery entitlement end to end, and remove it if no live feature depends on it.
6. Write down the methodology behind every derived or interpreted health metric shown on screen.
7. Prepare a reviewer demo account seeded with realistic HealthKit sample data — never an empty state.
8. Check screenshots show the real HealthKit feature in use, not placeholder or mock data.
9. Scrub PHI from debug logs and disable screen recording on screens rendering clinical values.
10. Re-read guideline 5.1.3(ii) against your actual data flow one more time before you hit submit.

FAQ

How long does Apple's review take for a HealthKit app?

Typical App Review turnaround is 24–48 hours, but HealthKit apps sometimes take longer on the first submission because a human reviewer checks the purpose strings and demo data manually rather than relying only on automated checks.

Can I appeal a HealthKit-related rejection?

Yes — you can reply directly in App Store Connect's Resolution Center with clarification, or request an App Review Board appeal if you believe the guideline was misapplied. A clear, specific reply citing the exact clause and your fix resolves most HealthKit rejections faster than a full appeal.

Does Android's Health Connect have the same restrictions?

Health Connect has its own permission model and data-use restrictions, but they aren't identical to HealthKit's App Review clauses — don't assume a purpose string or data-scope decision that passed on iOS will automatically satisfy Android's review.

Do I need a dedicated privacy policy page for HealthKit data?

Yes. Apple requires a privacy policy URL that specifically addresses how health data is collected, used, and shared — a generic app-wide privacy policy that doesn't mention health data is a common reason reviewers ask for clarification.

What's the single most common reason HealthKit apps get rejected?

Requesting HealthKit data types the shipped app doesn't visibly use. It's a mechanical check reviewers run early, and it's also the easiest one to fix before you submit.

Can a wellness app add medical claims later without a new review tier?

No. Adding interpretive or diagnostic language — a risk score, a dosing suggestion — changes how Apple reviews the app and can trigger a request for regulatory documentation that a pure wellness app never needed.

Primary source: Apple App Store Review Guidelines.