Guideline 1.4.1 — medical and health apps
Health apps are reviewed harder, and the thing that gets them rejected is usually a sentence rather than a feature.
Guideline 1.4.1 puts medical apps under greater scrutiny. Apps that could provide inaccurate data, or be used to diagnose or treat, must disclose the data and methodology supporting them, and accuracy or clinical-effect claims that cannot be supported are a rejection reason.
In practice that means the risk lives in your copy. "Validated," "clinically proven," "accurate to within," "detects," "diagnoses" each invite a reviewer to ask for the evidence, and the absence of it is the rejection.
The reliable design answer is to describe what the app records, not what it determines. An app that logs a symptom and produces a summary is a record-keeping tool. An app that tells you what the symptom means is a medical device claim, and everything downstream gets harder.
The three guidelines that travel together
1.4.1 — greater scrutiny and disclosure. If your app could produce inaccurate data or be used to diagnose or treat, you must disclose the data and methodology behind it.
1.4.2 — drug dosage calculators. These must come from the drug manufacturer, a licensed medical provider or an approved entity. This is the one that catches well-meaning tracking apps. An app that calculates or recommends a dose is in this territory; one that logs what was prescribed is not, and the distinction is worth designing around before you build rather than after you are rejected.
5.1.1 — highly regulated fields. Health apps handling sensitive data are expected to come from a legal entity rather than an individual developer account. Incorporate first. A rejection on this is slow to fix because it is not a code change.
Alongside these, 5.1.3 prohibits using HealthKit or health data for advertising or data mining, which constrains monetisation in ways worth knowing before you design a business model around it.
Copy that gets rejected, and what to write instead
| Do not write | Write |
|---|---|
| "Validated symptom tracking" | "Records the symptoms you log" |
| "Clinically proven to improve X" | "Produces a summary you can take to an appointment" |
| "Detects perimenopause" | "Records what you observe over time" |
| "Your score indicates severe symptoms" | "Your entries for the last eight weeks" |
| "Calculates your correct dose" | "Records the dose you were prescribed" |
| "Medical-grade accuracy" | Delete it |
"Validated" is the highest-risk single word in this category, because it has a specific meaning. Published instruments are validated. An app that references one is not, and an app that implements one may be doing so without a licence.
The instrument-licensing trap
This one catches apps that were trying to be rigorous.
The best-known menopause symptom instruments are the Greene Climacteric Scale and the Menopause Rating Scale, and both are licensed. RWS Life Sciences administers GCS permissions and states it is free to academic researchers while pharmaceutical companies pay per patient enrolled — with no published tier covering a commercial consumer app. RWS also states the instrument cannot retain its official name if items are altered, and that it was validated only for paper administration, with digital adaptations not validated. ZEG Berlin requires contact for commercial MRS licensing.
So an app that implements one has a licensing problem, and an app that implements a modified version has a naming problem on top. The clean path is your own originally-worded inventory over the same clinical domains — vasomotor, psychological, somatic, urogenital — which are clinical categories rather than anyone's property.
This is exactly why HormoneLog, Baker Ventures' own menopause app, implements neither and never describes itself as validated. What the scales are, and what a score can and cannot tell you.
Do this before submitting
- Grep your own copy for the trigger words: validated, clinical, proven, accurate, diagnose, detect, treat, medical-grade. Every hit needs either evidence you can produce or a rewrite.
- Check the same words in your App Store description and screenshots, not just the app. Metadata is reviewed too, and it is where marketing language survives longest.
- Confirm the app is not calculating or recommending a dose anywhere, including in a "suggested" or "typical" framing.
- Confirm you are submitting as a legal entity.
- Have a clinician review the health content and be able to say who, in Review Notes.
- Write the disclosure. What the app records, how, and what it does not determine. Put a short version in the app and a clearer version in the Review Notes.
- Check nothing displays a severity band derived from research-population cut-offs. Showing a user their number against those bands is an assessment.
What a static check can and cannot do here
Can: find trigger words in code strings, in the Info.plist, in App Store metadata and in screenshots; confirm HealthKit usage strings exist and match declared features; confirm the app is not shipping a dosing calculation; confirm account deletion and privacy-policy links resolve.
Cannot: decide whether a reviewer will read your framing as a medical claim. That is judgement, and 1.4.1 is one of the guidelines where judgement dominates.
shipcheck runs the first list locally before you build. It does not claim the second. What it checks.
Nothing here is legal or regulatory advice. FDA general-wellness guidance, App Store guidelines and instrument licensing terms all change, and a health app is one of the places where an hour with someone qualified is worth more than any checklist.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
What is App Store Guideline 1.4.1?
It covers medical apps, which receive greater scrutiny in review. Apps that could provide inaccurate data or be used to diagnose or treat must disclose the data and methodology supporting them, and claims about accuracy or clinical effect that cannot be supported are a rejection reason.
Does my health app need a clinician involved?
If it makes clinical claims or provides content that reads as medical guidance, having that content reviewed and signed off by a licensed clinician is the practical way to satisfy the disclosure and accuracy expectations. It is also the only defensible answer when a reviewer asks who validated it.
What is Guideline 1.4.2 and why does it matter for dosing?
It addresses drug dosage calculators, which must come from the drug manufacturer, a licensed medical provider or an approved entity. An app that calculates or recommends a dose is in that territory. An app that logs what was prescribed is not, and the distinction is worth designing around deliberately.
Can an individual developer submit a health app?
Guideline 5.1.1 addresses apps in highly regulated fields, and health apps handling sensitive data are expected to be submitted by a legal entity rather than an individual developer. Incorporate before submitting rather than after being rejected.
What gets health apps rejected most often?
Claims the app cannot support. Saying an app is validated, clinically proven, or accurate to some standard invites the reviewer to ask for the evidence, and the absence of it is the rejection. Describing what the app records rather than what it determines avoids the whole category.
shipcheck. “Guideline 1.4.1 — medical and health apps.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/guideline-1-4-1-medical-apps/