Apple Rejected My AI Body App Twice — the Exact Guidelines and Fixes

Key takeaways

• 5.1.1(iv) is about pressure, not permissions: a neutral "Continue" button and no forced Settings redirect fixed it — keep an alternative (photo library) visible so a denial never dead-ends.
• 1.4.1 wants receipts: every health number the app shows needs a citation reachable in about one tap; we cited NIH, WHO, ACE, ISSN and peer-reviewed papers.
• Reading HealthKit obligates a privacy-policy line disclosing it — easy to forget if your policy only mentions photos.
• Cost math: review is ~1 day (90%+ within 24h per Apple); the fixes are the expensive part — two rejections added roughly 5–8 days for us.
• Resubmit a fresh build, not an over-the-air patch — App Review tests the binary you upload.

I'm building Bodilab AI, an app that estimates body composition from a photo, as a solo founder. Apple rejected it twice before it went through. Rejection emails read like verdicts, but they're really a diff — Apple is telling you the exact rule to change. So here are the exact guideline numbers, the exact wording Apple flagged, and the exact code and content changes that resolved each, plus a rough cost estimate and the hidden issue I caught before a third strike. If you ship a fitness or health app, this should save you a cycle.

Definition, so the numbers below make sense: an App Store Review Guideline is a numbered rule in Apple's published App Review Guidelines; when your app is rejected, the Resolution Center note cites the specific number (like "5.1.1(iv)" or "1.4.1") that your build violated. Fix that exact rule and resubmit.

What exactly did Apple reject, and under which guidelines?

Two guidelines, in two separate rejections: 5.1.1(iv) (Access) for the camera permission flow, and 1.4.1 (Physical Harm) for showing health figures without citations. Here's the map I wish I'd had before submitting — what each rule actually means in plain English, what trips a body/fitness app, and the direction of the fix:

Source: Apple's published App Review Guidelines (guideline numbers and their scope); the "what trips a body app" and "fix direction" columns are my first-hand experience with Bodilab AI, not Apple text.

Why did Apple flag the camera permission flow under 5.1.1(iv)?

Because our flow pushed the user toward "yes" instead of leaving them in control — that's the whole point of 5.1.1(iv). Apple flagged two specific things in how we asked for the camera:

The principle: a permission request must give the user control, not funnel them toward "yes." You're allowed to show a Settings link when a feature genuinely can't work without access — but it has to be the user's tap, not an automatic redirect. We also kept a "choose from library" path visible the whole time, so denying the camera never dead-ends. That fallback is the non-obvious part: reviewers don't just want neutral wording, they want proof the app still functions when the user says no.

Why did Apple reject the health info under Guideline 1.4.1?

Because the app showed health recommendations and calculations without citing where the numbers came from — that's exactly what 1.4.1 (Physical Harm) polices. The reviewer's note read: the app "provides health or medical recommendations and calculations in the onboarding and AI coach without citations." Our onboarding shows a weight projection, and the AI coach gives protein and calorie guidance — all with no sources.

The fix was a dedicated "Sources & references" screen, linked from the profile tab, the onboarding step where the projection appears, and the coach. It lists every health/nutrition figure the app uses, each with a link to an authoritative source:

Two things mattered: the citations had to be easy to find — as a rule of thumb (mine, not an Apple-published number) I assume any screen stating a health figure a user could act on needs a citation reachable in about one tap — and I kept the app framed as fitness/wellness with estimates, not a medical device, with non-medical disclaimers throughout. Citing the accuracy of the body-fat estimate itself to the arXiv study (~2–3 points vs DEXA in research conditions) turned out to matter as much as citing the nutrition figures — it's a "health calculation" too. An earlier round had also flagged medical-sounding words like "diagnosis" and "prescription," which I'd already neutralized to "analysis" and "plan."

How long does two rejections actually cost you?

The review itself is fast — Apple reports over 90% of submissions are reviewed within 24 hours (per Apple's App Review page) — so the expensive part is your fix time between cycles, not the wait. Here's the worked example from my own timeline, with the fix estimates labeled as estimates:

Review-wait figures: Apple's published "90%+ within 24 hours" statistic. Fix-time figures: my own rough estimates for Bodilab AI (n=1), not Apple data — a solo founder's pace; a team could compress the fixes into a day.

The honest takeaway: a rejection rarely costs you review time — it costs you rebuild-and-retest time. The 1.4.1 fix was slow not because citing sources is hard, but because I had to hunt down an authority for every number the app displays and wire the screen into three entry points. The cheapest reviewer you'll ever have is the one who rejects you before your users do; the second-cheapest is the pre-submission audit you run yourself.

What hidden issue did the pre-submission audit catch?

A likely third strike: our privacy policy never mentioned Apple Health, even though the app reads HealthKit data. Two rejections in, I stopped guessing and ran a full pre-submission audit. The app reads HealthKit data (weight, body fat, steps, sleep, resting heart rate), and Apple requires the privacy policy to disclose health-data use. I added a section spelling out that we read only (never write to HealthKit), keep it on-device, only send weekly-average summaries to the AI for coaching, and never sell it or use it for ads.

The audit also caught smaller things reviewers dislike: a visible reset button labeled "(dev)" (renamed to "Delete all data"), and an internal "scoring engine" debug row (hidden in production). Individually trivial — together they read as an unfinished app, and "looks unfinished" is a soft trigger for scrutiny under several guidelines at once. I also went back and made sure the App Privacy questionnaire matched reality: we declared Health & Fitness, Photos, Usage Data and Purchases, all "not linked to you," with no tracking. A mismatch between what the questionnaire says and what the binary does is its own rejection reason.

How do you avoid a fitness-app rejection in the first place?

Match your pre-submission effort to how much health data your app touches — it's a ladder, not a single checklist, because a step-counter and an AI coach carry very different review risk. Graduated guidance:

• Tier 1 — light fitness (timers, logging, no health advice): keep permission requests neutral, add a plain non-medical disclaimer, and fill the App Privacy questionnaire accurately. That's usually enough.
• Tier 2 — you show health numbers (calories, BMI, body-fat, projections): everything in Tier 1, plus a citation for every figure reachable in about one tap, and framing as "estimates / wellness," not diagnosis. This is where most fitness apps get caught by 1.4.1.
• Tier 3 — you read HealthKit or give AI coaching: everything above, plus an explicit HealthKit section in your privacy policy, a clear read-only/on-device stance, and no medical-sounding verbs ("diagnosis", "prescription"). Run a pre-submission audit before you submit at all.

And the short list I'd hand another founder, regardless of tier:

• Cite every health number, somewhere easy to find. AI answer engines and reviewers both reward it.
• Keep permission requests neutral — "Continue", never a forced Settings redirect, always a fallback.
• Disclose HealthKit in your privacy policy if you touch it.
• Be a "wellness app with estimates," not a medical device — and say so, with disclaimers.
• Bake fixes into a fresh build for re-review; an over-the-air update may not reach the review binary reliably.

Where does Bodilab AI honestly sit in all this? Not as some rejection-proof template — it took two rejections to get right, and I'm telling you exactly where it failed. Its actual edge is the answer-check: it estimates body fat and lean mass, breaks it down by body part, and shows the weekly trend, so you can tell whether your effort is working — and every health figure it shows is now cited, which is as good for a curious user as it was for the reviewer. If you want the measurement side, see the best ways to measure body fat and where photo AI apps fit among them.

FAQ