Apple's App Store Review Guidelines are organized into five sections: Safety, Performance, Business, Design, and Legal. Most rejections come from a handful of rules: incomplete apps or missing demo accounts (2.1), inaccurate metadata (2.3), copycat or spam apps (4.3), thin web wrappers (4.2), digital goods sold outside in-app purchase (3.1.1), and privacy problems such as missing account deletion (5.1.1). Reading those rules before you build prevents most delays.
How the guidelines are organized
The guidelines open with a short introduction and then five numbered sections. Safety (1) covers objectionable content, user-generated content, kids, and physical harm. Performance (2) covers completeness, beta builds, accurate metadata, and hardware compatibility. Business (3) covers payments and in-app purchase. Design (4) covers copycats, minimum functionality, spam, and sign-in. Legal (5) covers privacy, intellectual property, and gambling.
Rejection messages cite a guideline number, so learning the structure turns a confusing notice into a specific to-do. Apple updates the document several times a year, often after WWDC, and changes can affect apps that were approved before. Subscribe to the developer news feed and re-read the sections relevant to your business model after each update.
2.1 App Completeness: the most common rejection
Guideline 2.1 requires that the submitted build is final, works, and can be fully reviewed. Crashes, placeholder text, broken links, empty screens, and features that require a login without a demo account all fall here. Apple's own transparency reporting has repeatedly listed performance and completeness issues among the top reasons apps are rejected.
Prevent it by testing a fresh install on a real device, providing a working demo account with sample data, and describing any hardware, location, or account requirements in the review notes. If a feature depends on a server, confirm that the server is reachable from outside your network. A short screen recording linked in the notes can resolve questions before they become rejections.
2.3 Accurate Metadata: your listing is reviewed too
Guideline 2.3 covers the name, subtitle, keywords, description, screenshots, and previews. Screenshots must show the app in use, not just splash screens or marketing art. Keywords must not include other apps' trademarks or irrelevant popular terms, and the name and subtitle should not be stuffed with generic phrases. References to other platforms, such as Android, are not allowed in metadata.
Metadata rejections are a reminder that white hat ASO is also faster ASO. Keep claims verifiable, avoid unprovable superlatives, and make sure every feature in the screenshots exists in the build. Our guides to the App Store keyword field and screenshot captions show how to stay persuasive within the rules.
3.1.1 In-App Purchase and payments
If you sell digital goods or services used inside the app, such as premium features, subscriptions, or virtual currency, guideline 3.1.1 generally requires Apple's in-app purchase. Physical goods and services consumed outside the app, such as rides or groceries, use other payment methods. Reader apps, some business apps, and certain regions have exceptions, and court rulings and regulation have changed the rules on linking to external purchases in the United States and the European Union.
Because this area changes often, check the current guideline text and Apple's regional pages before designing a paywall. The way you describe pricing also matters: subscription terms must be clear before purchase. Our guides to subscription messaging and App Store fees cover the commercial side.
4.2 and 4.3: minimum functionality and spam
Guideline 4.2 rejects apps that are little more than a repackaged website, a simple list, or a marketing brochure. Apple wants apps to offer native features and lasting value beyond what a browser provides. If your app is mostly web content, add capabilities that justify an app, such as offline access, notifications, device integrations, or personalized tools.
Guideline 4.3 targets spam: many near-identical apps, template apps with only cosmetic changes, and saturated categories with nothing new. Agencies and white-label developers hit this often. Consolidate variants into a single app with in-app configuration, or publish from the client's own account, as Apple's guidelines expect for template-based apps.
5.1 Privacy: data collection, account deletion, and tracking
Guideline 5.1.1 requires a privacy policy, permission requests that explain why data is needed, and data minimization. Since 2022, apps that let users create an account must also let them start account deletion from within the app. Requests for permissions such as location or contacts must be tied to features the user can see.
Guideline 5.1.2 covers data use and sharing, including App Tracking Transparency. Apps may not require tracking consent to access features, and must not offer incentives for allowing tracking. Make sure your App Privacy details match what SDKs actually collect; inconsistencies are increasingly caught in review. See our ATT prompt guide for compliant pre-permission screens.
How to respond to a rejection
Read the message carefully and reply in the Resolution Center if something is unclear. Often a rejection is resolved by adding information rather than changing code, such as a demo account or an explanation of how a feature works. If you believe the reviewer misunderstood the app, explain it politely with screenshots or a video.
If you disagree with a decision, you can file an appeal with the App Review Board, and you can suggest changes to the guidelines themselves. Bug-fix submissions are generally not held up for unrelated guideline issues, except legal ones. Our app rejection recovery guide covers the full diagnose, fix, and resubmit process.
How to do it, step by step
- Read sections 2, 3, and 5 before buildingThese cover completeness, payments, and privacy, which drive most rejections. Note any rules that affect your business model or data use.
- Run a reviewer-style test passInstall the build fresh on a real device, sign in with the demo account, and open every screen shown in your screenshots.
- Audit metadata against guideline 2.3Remove trademarks, competitor names, platform references, and unverifiable superlatives from the name, subtitle, keywords, and screenshots.
- Reconcile privacy disclosures with SDKsList every SDK, record what it collects, and update App Privacy details and the privacy policy to match.
- Write complete review notesProvide credentials, explain non-obvious features, and link a short video for hardware-dependent or location-dependent functions.
Before and after examples
Illustrative examples written for a generic app in this category, not client results. Swap in your own product, audience, and data.
Resubmit the same build with no notes.
Add a demo account with preloaded content, explain where the subscription screen is, and attach a 60-second walkthrough video.
Why it works: Most completeness rejections are about the reviewer's access, not your code.
Keywords: tiktok,instagram,capcut,editor,video
Keywords: reels,shorts,trim,captions,transitions,templates,music,vlog
Why it works: Competitor trademarks invite rejection; feature and use-case terms are allowed and attract the same intent.
Email support@example.com to delete your account.
Settings, then Account, then Delete account, with a confirmation step and a clear note about retained data.
Why it works: Apple requires apps with account creation to let users initiate deletion in the app.
Action plan
- Learn the five sections and their numbers
- Provide a working demo account every time
- Keep metadata free of trademarks and platform names
- Use in-app purchase for digital goods unless an exception applies
- Offer in-app account deletion
- Reconcile App Privacy details with every SDK
- Reply in the Resolution Center before resubmitting
Metrics to monitor
- First-pass approval rate
- Rejections by guideline number
- Average days lost per rejection
- Share of rejections fixed without a new build
Record the baseline, release date, audience, markets, and external changes before interpreting movement. Rankings and conversion are useful signals, but a decision is stronger when activation, retention, and business value confirm that the page attracted the right users.
Frequently asked questions
What is the most common reason for App Store rejection?
Performance and completeness issues under guideline 2.1, such as crashes, placeholder content, broken links, and missing demo accounts, are consistently among the most frequent rejection reasons Apple reports.
Can I mention Android in my App Store listing?
No. Guideline 2.3 does not allow references to other mobile platforms in metadata, unless there is specific interactive functionality that requires it.
Do I have to offer account deletion in my app?
Yes, if users can create an account in your app. Apple requires that they can start account deletion from inside the app, not only by email or a website form.
How do I appeal an App Store rejection?
Reply in App Store Connect's Resolution Center first. If you still disagree, submit an appeal to the App Review Board with a clear explanation of why the app complies.
Keep reading
Go deeper on this topic
More in Policy and Compliance
Browse all 7 Policy and Compliance guides
Work with ASOWin
Primary sources
Platform capabilities and limits can change. Verify current requirements in these official resources:
