How to Fix App Store Guideline 1.4.1 Medical App Rejection

Separate unsupported health measurements from documented medical functionality, then prepare the methodology, safety, and regulatory evidence Apple can verify.

What this rejection usually means

Guideline 1.4.1 applies when a medical app could provide inaccurate information or be used to diagnose or treat patients. Apple requires clear disclosure of the data and methodology supporting health-measurement accuracy claims, says it will reject an app when the claimed accuracy or method cannot be validated, asks medical apps to remind users to consult a doctor before medical decisions, and asks for a link to regulatory clearance when the app has received it. The recovery therefore starts with the submitted product's real intended use and outputs. Calling a feature “wellness,” adding “not medical advice,” or pointing to similar approved apps does not by itself answer whether the exact capability is accurate, safe, documented, and appropriately declared.

Likely rejection signals

• The app estimates, predicts, scores, screens for, diagnoses, monitors, prevents, or recommends treatment for a disease or physiological condition
• Results use clinical-sounding labels, risk bands, thresholds, alerts, treatment instructions, or urgent calls to action without a documented basis
• Accuracy percentages, correlations, “clinically proven” language, or medical comparisons appear in the app, screenshots, metadata, website, or ads
• The method depends only on iPhone or Apple Watch sensors for a measurement Apple identifies as impermissible without appropriate validation or hardware
• The submitted method summary omits the source data, reference standard, study population, sample size, metrics, limitations, or intended-use boundaries
• The app's regulated-device status, manufacturer information, intended use, safety information, or instructions-for-use URL is missing or inconsistent by region
• The user can act on a result without a visible limitation, escalation path, or reminder to consult a doctor before medical decisions
• The review account, supported hardware, sample data, or exact workflow needed to evaluate the medical feature was not available to App Review

Recovery plan

1. Preserve the complete rejection, reviewer attachments, submission ID, app version, build number, review date, device and OS, exact archive, active backend model or ruleset, and all store metadata and marketing that were live during review.
2. Create a claims-and-capabilities inventory for the exact release. Record every measurement, score, prediction, diagnosis, monitoring function, treatment suggestion, alert, threshold, stated accuracy, intended user, intended use, input source, and resulting user action.
3. Classify each item by what the product actually does rather than the label you prefer. Separate passive logging, general education, wellness guidance, clinical measurement, screening, diagnosis, monitoring, prevention, and treatment. Obtain qualified regulatory advice when classification is uncertain; App Review documentation is not a substitute for legal or regulatory analysis.
4. Build a validation map for every retained accuracy claim. Identify the sensor or input data, algorithm or rule version, validation protocol, comparison or reference standard, study population, sample size, performance metrics, error range, known limitations, excluded populations, and the public or reviewer-accessible evidence that supports the claim.
5. Remove or materially redesign any output whose method or accuracy cannot be validated. Do not keep the same capability behind a disclaimer, remote flag, renamed label, or less prominent navigation. Verify the release binary, production backend, downloaded models, deep links, widgets, and cached states.
6. Align the intended use everywhere. Update onboarding, result screens, alerts, help text, screenshots, description, keywords, website, ads, and review notes so they do not imply diagnosis, treatment, clinical accuracy, or medical decision support beyond the evidence and applicable authorization.
7. Add appropriate safety context for retained medical functionality. State material limitations where users see the result, define what the output can and cannot establish, provide a safe failure state, and remind users to consult a doctor in addition to the app and before making medical decisions, as Apple requests.
8. Reconcile regulatory status by country or region. If the app is a regulated medical device, complete App Store Connect's declaration with applicable manufacturer or operator identifiers, instructions for use, intended-use statement, safety information, and authentic authorization details. If it is not regulated, retain the analysis supporting that answer without presenting it as Apple's approval.
9. Give App Review a reproducible path. Provide stable credentials or an approved demo mode, required compatible hardware, seeded representative data, numbered steps, and a short recording from a clean install of the processed release. Attach the method summary and applicable regulatory links in App Review Information.
10. Choose one accurate recovery route. Submit a new build when capability, claims, safety text, model, remote behavior, or reviewer access changed. Reply with the same build only when the app is already compliant and the problem is limited to missing review information. Appeal only when preserved, build-specific evidence directly contradicts the finding.

Evidence to prepare

• Complete rejection, reviewer attachments, submission ID, version, build, device, OS, review date, and preserved release archive
• Claims-and-capabilities matrix mapping every output to intended use, input data, method, stated accuracy, user action, and in-app disclosure
• Validation summary with protocol, reference standard, population, sample size, performance metrics, error bounds, limitations, and source links
• Versioned inventory of algorithms, models, rules, remote configuration, datasets, supported hardware, and production endpoints used by the reviewed release
• Applicable regulatory authorization, registration, clearance, or conformity documentation tied to the correct entity, intended use, version, and region, without redacted facts needed for verification
• App Store Connect regulated-medical-device declarations, instructions-for-use URL, intended-use statement, safety information, and region availability
• Annotated screenshots showing claims, limitations, doctor reminder, safe error states, and the exact path to each medical or health output
• Clean-install recording and reviewer instructions covering credentials, hardware, sample data, production backend, and every cited feature
• Before-and-after matrix identifying each completed product, claim, documentation, metadata, or access change in the submitted state

Appeal or fix first?

Reviewer response framework

Your response should be factual, short, and limited to the submitted build. Cover these points:

1. Identify the exact app version, build number, feature, output, and Guideline 1.4.1 wording being addressed.
2. State the feature's intended use, input data, method, validation evidence, limitations, and what users are told before acting on the result.
3. List only changes completed in the submitted build, production backend, metadata, review information, and regional declaration.
4. Provide numbered review steps, compatible hardware and credentials, a clean-install recording, and direct links to the methodology and applicable regulatory documentation.
5. If the evidence already supported the reviewed capability, ask Apple to identify the specific claim, screen, result, or document that remains unverifiable.

Frequently asked questions

Source: Apple App Review Guidelines — 1.4.1 Medical Apps. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.