Review Guidelines & Common Rejections
Know the high-frequency clauses of the App Store Review Guidelines: feature availability, privacy compliance, content legality, and payment compliance. Understanding the user experience behind a clause is more useful than memorizing clause numbers.
High-Frequency Concerns
| Concern | Requirement | Typical rejection |
|---|---|---|
| Feature availability | No crashes, blank pages, or unavailable core features | 2.1 Major functionality unavailable |
| Misleading | Description, screenshots, IAP display must match reality | 2.3 Misleading metadata |
| Privacy & data | Clear permission purposes; consent before collection; no unauthorized tracking | 5.1.x Privacy non-compliance |
| Payment | Digital content must use IAP; no third-party payment redirect | 3.1.1 Non-IAP sales |
| Accounts & login | Provide demo accounts; social login parity; allow account deletion | 5.1.1(v) No delete entry |
Reading Common Rejection Clauses
- 2.1 (Functionality): crashes, freezes, or unavailable core features. Prevention: real-device self-test + TestFlight internal testing before submission.
- 3.1.1 (Payment): selling digital content/memberships via non-IAP, or redirecting to third-party payment. Prevention: always use IAP for digital content.
- 5.1.x (Privacy): privacy declarations, permission purposes, or missing account-deletion entry. Prevention: honest nutrition labels, specific permission descriptions.
- 4.2 (Minimum functionality): rough appearance / sparse content judged as “minimum functionality”. Prevention: ensure sufficient content and features.
- 1.2 / 1.4 (Content): illegal or inappropriate content (porn, gambling, hate, etc.). Prevention: content review and compliance self-audit.
Account deletion is a newer hard requirement: if your app supports account registration, you must provide an “Delete Account” entry in-app. This is easily overlooked yet a high-frequency 5.1.1 rejection item.
Prevention Strategies
- Self-test before submission: core flows, IAP, login, push, permission prompts.
- Write clear review notes: test path, accounts, environment; disclose hardware/region requirements.
- Privacy reconciliation: confirm the privacy policy and labels match actual data collection.
- Study rejection cases: follow Apple developer forums and common rejection lists.
- Maintain version quality: use TestFlight to keep issues out of review.
Self-Check List
- Core features verified on real devices; no P0 crashes
- Description/screenshots/IAP display consistent with reality
- Digital content uses IAP; no third-party payment guidance
- Privacy labels and permission descriptions match reality
- Account-based apps provide a delete-account entry
- Review notes include test path and accounts
FAQ
- How soon can I resubmit after rejection? After fixing, you can resubmit; processing is usually faster. Don’t resubmit the same problem version repeatedly.
- How do I know a rejection is mistaken? Read the reason carefully; if it’s genuinely a mistake, explain via Resolution Center or request a phone call.
- How often do the guidelines change? Apple updates them periodically; review the latest official guidelines before each submission.