Why apps get rejected, and how to submit so yours does not
First submissions are frequently rejected, and the causes are a short, predictable list. Every one of them can be checked before you submit.
Key takeaways
- Most rejections are access failures, crashes, privacy mismatches, payment rule breaches, or minimal functionality.
- Provide a working demo account already in the state needed to see every significant feature.
- Third-party SDKs are the usual cause of privacy declarations disagreeing with actual behaviour.
- Budget two review cycles for a first submission and never announce a date that assumes one.
App review rejections cluster around a small set of causes: incomplete information for the reviewer, crashes and broken links, privacy declarations that do not match actual behaviour, payment rules, and apps that reviewers judge to offer too little. Almost all are avoidable with a pre-submission checklist, and the cost of failing is a review cycle measured in days at a moment when you have already announced a date.
The most common causes
- The reviewer could not get in. No demo account, expired credentials, or a one-time password sent to a phone the reviewer does not have. Provide a working account with full access and a note explaining anything unusual.
- Crashes and dead ends. Reviewers test on current devices and the latest operating system. Test there too, not only on the team's own handsets.
- Privacy labels that disagree with behaviour. If any SDK collects an identifier, it must be declared. Third-party analytics and advertising libraries are the usual source of a mismatch nobody intended.
- Payment rules. Digital goods and services consumed in the app generally must use the platform's in-app purchase system. Routing users to an external payment page for digital content is a reliable rejection.
- Minimal functionality. An app that is a wrapper around a website, or offers little a browser does not, is judged as not warranting a place in the store.
Submitting well
Write review notes as though the reviewer knows nothing about your business, because they do not. Explain what the app is for, how to reach each significant feature, and why anything unusual is there. If a feature requires a specific state, such as an existing order or a verified account, set that state up in the demo account before submitting rather than describing how to create it.
Make sure your support URL and privacy policy URL resolve. Broken links in the listing are a rejection cause that costs a full cycle for something fixable in a minute.
If you are rejected
Read the specific guideline cited rather than guessing. Where you disagree, reply in the review system with a clear explanation; this is a normal part of the process and reviewers do reverse decisions. Where you agree, fix and resubmit rather than arguing, since a resubmission is usually faster than an appeal.
Plan for it
Budget two review cycles for a first submission and submit at least a week before any date you have committed to publicly. Announcing a launch date that depends on a first-time review passing immediately is a risk with no upside.
Set up the demo account's state before submitting. Do not describe how the reviewer could create it.
Sources