The release was scheduled, the marketing was booked, and review rejected the build. Rejections cluster around a small number of recurring causes, and nearly all of them are known well before submission. Treating store requirements as engineering work rather than a final administrative step removes most of the risk.
01Account deletion must exist in the app
Any app that lets users create an account must let them delete it from within the app. A link to a web form, an email address to contact, or a support process does not satisfy this. It must be reachable in the interface and it must actually delete the account rather than deactivate it.
This catches teams repeatedly because deletion is genuinely complex on the backend - retention obligations, referential integrity, anonymisation of records that must be kept. That complexity is why it gets deferred, and why it becomes a release blocker.
| Cause | Requirement |
|---|---|
| No in-app account deletion | Deletion available in the interface |
| Privacy declarations inaccurate | Must match actual SDK behaviour |
| Permissions requested without context | Explain the purpose before prompting |
| External payment for digital goods | Use in-app purchase where required |
| Incomplete demo credentials | Reviewer must reach all functionality |
| Placeholder content in the build | Ship finished screens only |
| Crash on the reviewer's device | Test on the oldest supported OS |
02Privacy declarations must match reality
The declared data collection must reflect what the app and all its dependencies actually do. Analytics, crash reporting, advertising and attribution SDKs collect data on your behalf, and their behaviour is attributed to you regardless of whether you wrote that code.
Audit dependencies before declaring. A third-party SDK collecting an advertising identifier while your declaration states you collect nothing is a straightforward rejection, and it is discovered by automated analysis rather than by chance.
03Give the reviewer everything they need
A reviewer who cannot access core functionality rejects the build. Provide working demo credentials that do not expire, and if the app requires an organisation, hardware, a physical card or a specific region, supply a demo account already configured with those and explain how to reach the main features.
Attach a short video for anything non-obvious. Review is time-boxed, and functionality that cannot be found within that window is functionally absent from the reviewer's perspective.
| Item | Verified by |
|---|---|
| Account deletion works end to end | Deleting a real test account |
| Demo credentials valid | Fresh login before submitting |
| Privacy declarations match SDKs | Dependency audit |
| Permission prompts explained | Reviewing each prompt in context |
| No placeholder screens | Walking every navigation path |
| Runs on oldest supported OS | Testing on that version |
04Permission prompts need context first
Requesting location, camera, contacts or notification access at launch, with no explanation, is both a rejection risk and a conversion problem. Users deny permissions they do not understand, and denial is often permanent without a trip to system settings.
Show a brief explanatory screen before the system prompt, describing what the permission enables. This improves acceptance rates substantially and satisfies the requirement that the purpose be clear.
05Appeal when the rejection is a misunderstanding
Reviews are performed by people under time pressure and mistakes happen. If your app was rejected for something it does not do, or the reviewer could not find a feature that exists, respond through the resolution centre with specific detail - screenshots, exact navigation steps, a video.
Keep the tone factual and precise. Well-evidenced appeals are resolved reasonably often, and it is faster than rebuilding and resubmitting when the build was never the problem.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer