Bodilab AIApple Rejected My AI Body App Twice — the Exact Guidelines and Fixes
Bodilab AI was rejected twice: Guideline 5.1.1(iv) for the camera permission flow, and Guideline 1.4.1 for health info without citations. The fixes that passed: a neutral "Continue" button with no auto-redirect to Settings, and a "Sources & references" screen citing every health figure. A pre-submission audit also caught a hidden one — our privacy policy never disclosed Apple Health (HealthKit) use. Here's exactly what each said and exactly what I changed.
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. Rejections are vague-sounding until you've hit them — so here are the exact guideline numbers, the exact wording Apple flagged, and the exact code/content changes that resolved each. If you ship a fitness or health app, this should save you a cycle.
Rejection 1 — Guideline 5.1.1(iv): the camera permission flow
Apple flagged two specific things in how we asked for the camera:
| What Apple flagged | What I changed |
|---|---|
| A pre-permission screen with a button labeled "Allow Camera" | Renamed it to a neutral "Continue" (Apple's guidance: use "Continue" or "Next", not "Allow") |
| The app redirected to Settings automatically after the user tapped "Don't Allow" | Removed the automatic redirect entirely. A user-initiated "Open Settings" button now appears only after a permanent denial |
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.
Rejection 2 — Guideline 1.4.1: health info without citations
1.4.1 is "Physical Harm." The reviewer's note: 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:
| Claim in the app | Cited source |
|---|---|
| Healthy weight-loss rate | NIH / NIDDK |
| Protein for muscle (g/kg) | ISSN Position Stand (2017) |
| Maintenance calories | Mifflin–St Jeor, Am J Clin Nutr (1990) |
| BMI categories | World Health Organization |
| Body-fat ranges | American Council on Exercise |
| FFMI reference | Peer-reviewed literature |
Two things mattered: the citations had to be easy to find (not buried), and I kept the app framed as fitness/wellness with estimates — not a medical device — with non-medical disclaimers throughout. (An earlier round had also flagged medical-sounding words like "diagnosis" and "prescription," which I'd already neutralized to "analysis" and "plan.")
The hidden one I caught before a third rejection
Two rejections in, I stopped guessing and ran a full pre-submission audit. It surfaced a likely third strike: our privacy policy never mentioned Apple Health. 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 stuff reviewers dislike: a visible reset button labeled "(dev)" (renamed to "Delete all data"), and an internal "scoring engine" debug row (hidden in production). Small, but they read as an unfinished app.
What I'd tell another fitness-app founder
- 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.
- 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.
- Fill the App Privacy questionnaire accurately (we declared Health & Fitness, Photos, Usage Data, Purchases — all "not linked to you," no tracking).
The app the story is about
Bodilab AI estimates your body-fat and muscle from one photo, and shows whether your effort is working. Body-composition figures are estimates, not medical advice.
Download on theApp StoreFAQ
Why did Apple reject the app under 1.4.1?
Because it showed health recommendations and calculations (a weight projection in onboarding, protein/calorie guidance in the coach) without citations. The fix was a Sources screen citing every figure with links to NIH, WHO, ACE and peer-reviewed papers, linked from several easy-to-find places.
What fixed the 5.1.1(iv) camera flow?
Renaming the pre-permission button from "Allow Camera" to "Continue", removing the automatic redirect to Settings after a denial, and only showing a user-initiated "Open Settings" after a permanent denial — with a library alternative always available.
Do I need to mention HealthKit in my privacy policy?
Yes, if your app reads HealthKit data. We added a section stating we read-only (never write), keep data on-device, send only weekly summaries to the AI, and never sell it or use it for ads.
Is an OTA update enough for re-review?
It's safer to bake fixes into a fresh build and submit that, since App Review tests the binary you upload and an over-the-air update may not reach it reliably during review.