App store review: the rejections you can predict
Store review is not arbitrary, and treating it as such is what makes it expensive. Most rejections come from a small, published set of rules that were knowable before the build started — and each one costs a review cycle, which lands at the worst point in a launch plan.
Part ofMobile App Development
The cost of a rejection is rarely the fix. It is the days waiting for the next review, repeated, against a launch date already communicated to other people. Reading the guidelines during scoping rather than after submission is the entire technique.
The recurring rejection reasons
Payments: the rule that decides business models
The distinction is between digital goods consumed inside the app and physical goods or services delivered outside it. The first generally requires store billing and its commission; the second generally does not and may not use it.
This is a commercial decision disguised as a technical one, and it has to be made before the business model is finalised rather than after. The rules also shift — regulatory action in several jurisdictions has changed what is permitted around linking to external purchase — so verify current terms for your markets rather than relying on what was true two years ago.
Privacy declarations must match reality, including your SDKs
Both stores require a declaration of what data the app collects and how it is used. The common failure is honest: the team declares what their own code collects and omits what an embedded analytics, advertising or crash-reporting library collects on their behalf.
- Inventory every third-party SDK and read each one's published data-collection disclosure.
- Check what identifiers are collected, including device identifiers used for advertising or attribution.
- Declare tracking accurately, since linking activity to a person across other companies' apps has its own consent requirement.
- Verify empirically by watching the app's network traffic on a test device, rather than trusting the documentation.
- Re-check when a dependency updates, because an SDK can begin collecting something new in a minor version.
Step four is the one that finds discrepancies. An SDK's documentation describes its intended behaviour; a proxy shows what actually left the device, and the two differ often enough to be worth the hour.
Permissions: ask late, and explain why
- Request at the point of use, not on launch. A location prompt on first open with no context is both a rejection risk and the reason people deny it
- Write a purpose string describing the user's benefit, not the technical need — "so we can show stores near you", not "to access location services"
- Request the narrowest scope — approximate rather than precise location, one-time rather than always, if that meets the need
- Handle refusal properly. The app must remain usable, in a degraded but coherent way, when a permission is denied
- Remove permissions you no longer use. Declared-but-unused permissions attract review questions and reduce installs
What to include with the submission
- Working test credentials, verified that morning — an expired demo account is a guaranteed rejection.
- Instructions for anything non-obvious, including how to reach features behind a specific state or role.
- A note on any hardware requirement, with a video if the feature cannot be exercised on a reviewer's device.
- An explanation for anything that looks like a rule violation but is not, pre-emptively.
- Accurate screenshots from the submitted build, not from a design file.
Point four saves the most time. If your app legitimately sells physical goods through an external payment flow, saying so in the review notes prevents a rejection that would otherwise cost a full cycle to explain.
When it is rejected
- Read the cited guideline number, not only the message — it states precisely what was applied
- Ask for clarification if the reason is genuinely ambiguous; that is a normal part of the process and faster than guessing
- Fix and resubmit with a note describing what changed, which makes the re-review quicker
- Appeal where you believe the rule was misapplied, factually and without argument — appeals do succeed
- Record every rejection and its resolution, because the same issue recurs across projects and teams
Plan the calendar around this rather than hoping. Submitting a week before a launch date leaves no room for one rejection, let alone two — and review times vary, so the buffer needs to be real rather than the minimum published figure.
Questions
What is the most common cause of app store rejection?
Missing in-app account deletion, for apps that let users create accounts. It must be doable inside the app rather than by emailing support, and the deletion must be real. It is also a data-protection obligation under regimes including India's DPDP Act, so it is worth building properly — identifying everything the account touches, deleting or anonymising it, and confirming to the user — rather than as a review checkbox.
When must I use store billing rather than my own payment provider?
Broadly, for digital goods and subscriptions consumed inside the app. Physical products, and services performed in the real world, generally use external payment and may not use store billing. The rules around linking out to external purchase have changed through regulatory action in several jurisdictions, so verify the current terms for each market you ship in rather than relying on what was true two years ago.
Why was my privacy declaration rejected as inaccurate?
Usually because it covers what your own code collects and omits what an embedded analytics, advertising or crash-reporting SDK collects on your behalf. Inventory every third-party SDK, read its published disclosure, and then verify empirically by watching the app's network traffic on a test device — documentation describes intended behaviour, and a proxy shows what actually left the device.
When should an app request permissions?
At the point of use, with a short in-app explanation before the system prompt, and at the narrowest scope that meets the need. Requesting on launch with no context produces denials, and a denied permission is much harder to recover than one never requested. The app must also remain usable in a degraded but coherent way when a permission is refused.