App Store and Play Store Review Rejections We've Learned From
Apple rejected a client's health app under Guideline 5.1.1 for collecting date of birth without a clear enough explanation of why, even though we had a privacy policy linked and a permission description string. The reviewer wanted the in-context explanation visible at the moment of collection, not just accessible via a link. We now write purpose strings and in-flow explanations together, reviewing both against the exact guideline language before submission rather than treating the privacy policy as sufficient coverage.
A recurring one on Android: Play Store rejections under the Data Safety section mismatching actual SDK behavior. A client's app used a third-party analytics SDK that collected device identifiers the client's own Data Safety form didn't disclose, because nobody had audited what the SDK actually sent versus what its documentation claimed. We now run a network traffic audit with a proxy tool against a release build before every Data Safety form submission, rather than trusting SDK vendor documentation.
We had a same-day dual-platform launch nearly slip a week because of Apple's Guideline 4.2 minimum functionality rejection on what was, in our assessment, a legitimate utility app with a narrow feature set. The reviewer's read was that it was too thin. We added two additional features that weren't originally scoped for launch, resubmitted with a detailed reviewer note explaining the use case, and it cleared on the second pass — the lesson being that 'this technically meets the guideline' isn't the same as 'a reviewer will agree it meets the guideline,' and it's worth building in review buffer time for exactly this kind of judgment call.
Sign in with Apple (Guideline 4.8) catches almost every client who adds a third-party social login without also offering Apple's option. We now flag this at the proposal stage, before any login UI is designed, because retrofitting Sign in with Apple after a login flow is built and tested costs real time and has caused at least one launch delay for us.
In-app purchase guideline 3.1.1 issues show up whenever an app references external payment or account creation in a way that reads as steering users off-platform, even indirectly — a support link that happens to mention a website subscription price triggered a rejection on one client project. We now audit all user-facing copy, not just the purchase flow itself, for language that could be read as directing users to pay outside the app.
None of these are exotic edge cases; they're guidelines every developer has read. What we've learned is that review outcomes depend heavily on how a specific reviewer interprets ambiguous language on a given day, so we now build a review buffer of at least 5-7 business days before any hard launch date, and we keep a running internal checklist of every rejection reason we've hit, updated after every submission.
