App Review rejections feel arbitrary from the inside, especially the first time. They aren't. Health and fitness apps get caught by a small, predictable set of guidelines, and the same four or five account for most of what we see.
The expensive part isn't the rejection itself — it's the cycle. A rejection two days before a launch date you've already announced, with a marketing spend committed, is a different problem from a rejection in week one of a two-week buffer. This page lists what actually catches health apps and what to do about each.
Guideline 1.4.1 — Physical Harm
This is the one health apps are most afraid of, and the one most likely to catch a product doing something genuinely interesting.
The guideline covers apps that could cause physical harm through inaccurate data or bad medical advice. The specific triggers:
- Drug dosage calculators. These must come from the drug manufacturer, a hospital, a university, a health insurance company, or a comparable certified body — or be approved by a regulator. A dosage calculator built by a startup is a rejection, and it's not appealable by explaining that the math is correct.
- Diagnosis from device sensors. Apps that claim to measure or diagnose a health condition using the phone's camera, microphone or motion sensors are expected to state their accuracy and methodology, and Apple has historically been skeptical of blood pressure, blood glucose, body temperature and similar claims from consumer hardware.
- Anything that could be relied on in an emergency. If your app might be a user's response to a medical emergency, expect scrutiny on what happens when it fails.
What to do: be honest about intended use in both the app and the metadata. If you make a measurement claim, be ready to document how it was validated. If you're in genuinely regulated territory, the question isn't App Review — it's whether you're a medical device, which is covered in is my wellness app a medical device and, from the store's perspective, in app store medical device labelling.
Guideline 5.1.3 — Health and Health Research
The HealthKit-specific rules, and the ones teams break by accident.
- HealthKit data must not be used for advertising, marketing or data mining. This includes sending it to an analytics platform that also serves ad targeting. The most common version of this violation is an SDK configuration nobody audited.
- You must not write false or inaccurate data to HealthKit. If you write estimated or derived values, they must be honest about what they are.
- A privacy policy is mandatory for apps using HealthKit, and it has to actually describe the health data handling, not just exist.
- Human subject research requires consent and ethics-board approval, and must disclose the nature of the research.
What to do: before submission, run a network capture on the app and look at what your analytics and crash-reporting SDKs are actually sending. Screen names and event names are the usual culprits — an event called glucose_reading_logged sent to an ad-supported analytics platform is the whole violation. Our wearable integrations work includes building to these rules rather than discovering them at review.
Guideline 5.1.1 — Data Collection and Storage
Several sub-rules, all of which health apps hit:
- Permission strings must be specific.
NSHealthShareUsageDescriptionsaying "we need access to your health data" is a rejection. Say what you read and why the user benefits. - Request permission in context, not all at once on first launch.
- Account deletion must be available in-app if the app supports account creation. Pointing users at a support email doesn't satisfy it.
- Sign in with Apple is required where you offer certain third-party sign-in options.
- Don't require personal information you don't need to function. A fitness app demanding date of birth, gender and full address before showing anything gets pushed back.
Guideline 2.1 — App Completeness (the demo account)
Boring, and probably the single most common rejection for health apps, because health apps are almost always behind a login.
Reviewers need a working demo account with populated data. An empty account showing an onboarding wizard and zero charts means the reviewer cannot evaluate your app, and they will reject rather than guess. If any feature requires a paired device, a connected wearable, a clinician account or a subscription, you have to make that reviewable too — pre-populated demo data, a video demonstrating the hardware flow, and clear notes in App Review Notes.
Health apps also fail this one on wearables: a reviewer with no Apple Watch cannot exercise your watch flows. Say so in the notes and attach a screen recording.
Guideline 3.1.1 — In-App Purchase
The line that catches fitness and wellness businesses: digital content and services consumed in the app must use in-app purchase. Real-world services delivered in person may use other payment methods.
So a subscription to workout videos, meal plans or an in-app coaching program is IAP. Booking a physical class at a gym, or paying a trainer for an in-person session, is not. Products that blend the two — a gym membership that also unlocks app content — are where teams get it wrong, and the safest path is to model the two revenue streams separately and be able to explain the split.
Guideline 4.2 — Minimum Functionality
If your app is substantially a wrapper around a website, it gets rejected. Health apps hit this when the mobile app is a webview of an existing patient portal or booking system with a native shell. Native functionality that justifies being an app — offline access, notifications tied to real events, HealthKit integration, device features — is the fix.
The metadata trap
A large share of health-app rejections have nothing to do with the binary. Your screenshots, description, keywords and app name can create a medical claim by themselves.
"Track your blood pressure" and "monitor your hypertension" are different claims. A screenshot showing a chart with a red "high risk" band is a claim. A keyword list containing a disease name attracts scrutiny you may not want. Review your metadata with the same eye you'd apply to advertising copy under health-claim rules, because it's held to a similar standard.
Metadata rejections are also the easy ones — they can usually be fixed and resubmitted without a new build, which is why it's worth submitting metadata early and separately where possible.
Google Play is a different set of rules
Don't assume passing Apple means passing Google:
- Health Connect data types require a declaration in Play Console describing your use of each type, reviewed against Google's health data policy. This can gate your production release.
- A permissions-rationale activity must be implemented so users can see why you want each health permission from inside Health Connect.
- Sensitive permissions (location in the background, activity recognition, camera) each need justification in the data safety form, and the form must match what the app actually does.
- Medical claims in the listing are policy-reviewed, same as Apple.
Pre-submission checklist
- [ ] Demo account with populated, realistic data, in App Review Notes
- [ ] Screen recording for any flow needing hardware the reviewer won't have
- [ ] Specific, benefit-explaining permission strings for every permission
- [ ] Privacy policy live, reachable, and describing health data handling
- [ ] In-app account deletion working
- [ ] Network capture reviewed: no health data reaching analytics or ad SDKs
- [ ] Metadata read for accidental medical claims — name, subtitle, description, screenshots, keywords
- [ ] Purchase model mapped against the digital/physical split
- [ ] Data safety form (Play) matching actual behavior
- [ ] Health Connect declaration submitted, if applicable
- [ ] A buffer of at least a week between submission and any announced date
When you do get rejected
Read the actual guideline cited, not the summary. Then respond in Resolution Center with a specific, factual explanation of what you changed or why the guideline doesn't apply — reviewers respond well to precision and badly to argument. If you believe the reviewer is wrong, there's a formal appeal path, and it's separate from resubmitting.
If a rejection lands on a date you've committed to, expedited review exists and is worth requesting once, with a real reason. Using it for a self-inflicted deadline burns credibility you may want later.
We publish app-store release readiness at $599 and a full QA & Release Readiness package at $999 over 7 days — test strategy, critical journeys, a device matrix, a prioritized defect report and a written go/no-go recommendation. Details on the QA and release page and every price on the pricing page. If you're staring at a rejection now, send us the notice and we'll tell you whether it's a metadata fix or a build change.
Frequently asked questions
How long does App Store review take for a health app?
Most reviews complete within a day or two, but health apps with medical claims, HealthKit usage or unusual sensor features can take longer if the reviewer escalates. Plan a week of buffer before any announced launch date, and more for a first submission.
Will using HealthKit get my app rejected?
No — HealthKit is a supported framework and thousands of apps use it. What gets rejected is HealthKit data flowing to advertising or analytics, vague permission strings, a missing or inadequate privacy policy, or writing inaccurate data. Build to 5.1.3 and it's a non-event.
Can I say my app treats anxiety or depression?
Treatment claims move you toward being a regulated medical device and attract review scrutiny on both stores. General wellness positioning — stress management, mood tracking, relaxation — is a different claim with a different regulatory posture. This is a decision to take deliberately, with the marketing copy written afterward rather than before.
What's the most common rejection for health apps?
In our experience it's the demo account — an app behind a login that a reviewer can't get into, or can get into and finds empty. It's also the cheapest to prevent: a populated demo account and clear reviewer notes take an hour.
Do we need a privacy policy even if we don't collect data?
Yes. Both stores require a privacy policy URL, and any app using HealthKit specifically requires one that describes health data handling. If you're also making HIPAA claims, note that the policy and the architecture need to agree — see HIPAA-compliant app development.