Guide · App StoreUpdated September 29, 2026
App Store rejection: what the guideline number means and how to get approved
An App Review rejection names one or more guideline numbers. Each number points to a specific rule, and most have a known fix. This guide lists the guidelines behind the most common rejections as Apple words them, then the ways back: reply, fix and resubmit, request an expedited review, or appeal.
What Apple says about review
From Apple’s App Review pages, checked on September 29, 2026.
- Review time
- “On average, 90% of submissions are reviewed in less than 24 hours.” Apple: App Review
- Most common cause
- “On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness.” Apple: App Review
- Metadata rejections
- “If your app was rejected for a metadata issue, you can resubmit the same build after resolving the issue.” App Store Connect Help: Reply to App Review messages
- Appeals
- “Submit only one appeal per submission that didn’t pass review.” Apple: App Review
- Repeat rejections
- If an app “is repeatedly rejected for the same guideline violation”, review “will take longer to complete.” Apple: App Review Guidelines (last updated June 8, 2026)
- Guidelines version
- The App Review Guidelines were last updated on June 8, 2026. Apple: App Review Guidelines (last updated June 8, 2026)
The guidelines behind common rejections
The number in the rejection message is the section of the App Review Guidelines. These are the ones we see most, with what the rule asks for and the usual fix.
| Guideline | What it requires | Usual fix |
|---|---|---|
| 2.1(a) App Completeness | Final versions only: no placeholder content, working URLs, tested on-device, and demo account info “if your app includes a login”, with the back-end service turned on. | Fix the crash or broken flow, add a working demo account in App Review Information, and keep the backend up during review. |
| 2.1(b) In-app purchases | In-app purchases must be “complete, up-to-date, visible to the reviewer and functional.” | Make each configured product reachable in the build, or explain in the review notes why it cannot be found. |
| 2.3 and 2.3.3 Accurate Metadata | Description, screenshots and previews must reflect the app’s core experience. Screenshots must show the app in use, “not merely the title art, login page, or splash screen.” | Replace the screenshots or text. Metadata-only rejections can resubmit the same build. |
| 2.3.1(a) Hidden features | No hidden, dormant or undocumented features. New features must be described “with specificity” in the Notes for Review; generic descriptions are rejected. | Remove the hidden switch or document it, and write specific review notes. |
| 2.5.1 Software Requirements | Public APIs only, the currently shipping OS, and deprecated features phased out. | Replace the private or deprecated API and rebuild with the current SDK. |
| 3.1.1 In-App Purchase | Unlocking features or content in the app must use in-app purchase. Under 3.1.1(a), United States storefront apps do not need an entitlement for buttons or links to other purchase methods. | Move digital unlocks to in-app purchase, or confirm the storefront rules that apply to your link. |
| 3.1.2 Subscriptions | Auto-renewable subscriptions must provide ongoing value and last at least seven days; before asking a user to subscribe, describe clearly what they get for the price. | Rewrite the paywall so the price, period and contents are clear before purchase. |
| 4.2 Minimum Functionality | Features, content and UI that “elevate it beyond a repackaged website.” | Add native functionality the web version does not have, or rethink shipping it as an app. |
| 4.3 Spam | (a) no multiple Bundle IDs of the same app; (b) no apps “indistinguishable from what’s already widely available.” | Merge near-identical apps into one, or show in the notes what makes the app different. |
| 4.8 Login Services | An app that uses a third-party or social login for the primary account must also offer an equivalent login that limits data to name and email, lets users keep their email private, and does not track for ads without consent. Apple lists five exemptions. | Add a login option that meets the three conditions, or show that an exemption applies. |
| 5.1.1(i) Privacy policy | A privacy policy link in App Store Connect and inside the app, covering what is collected, third parties, retention and deletion. | Publish a complete policy and link it in both places. |
| 5.1.1(v) Account deletion | “If your app supports account creation, you must also offer account deletion within the app.” | Add in-app account deletion that actually deletes the account on the backend. |
| 5.1.2(i) Data sharing | Disclose where personal data is shared with third parties, “including with third-party AI”, get explicit permission, and use App Tracking Transparency to track. | Add the disclosure and consent step, and the tracking prompt where tracking happens. |
| 1.5 Developer Information | The app and its Support URL must include an easy way to contact you. | Fix the support URL and contact details. |
Wording from the App Review Guidelines, last updated June 8, 2026. Read the full section named in your rejection before changing code; this table is a map, not a substitute.
What to do after a rejection
1. Read the message and the guideline
The rejection lists the guideline numbers and usually a description or screenshot of what the reviewer saw. Read the full guideline text, not just the heading.
2. Decide: build, metadata, or misunderstanding
A crash or missing feature needs a new build. A screenshot or description problem does not: after fixing the metadata you can resubmit the same build. If the reviewer misread the app, reply with the explanation and evidence.
3. Reply in App Store Connect
In Apps, open the app, click the link about unresolved issues, then Resolve next to the submission and Reply to App Review. You can attach files such as screenshots or a screen recording. Replying needs the Account Holder, Admin or App Manager role.
4. Fix everything named, then resubmit
Address each guideline in the message and say what changed in the review notes. Repeated rejections for the same guideline make review take longer, so it pays to fix it fully the first time.
5. Expedited review, when it is justified
Apple accepts expedite requests for a critical bug fix, with steps to reproduce the bug, or for an app tied to an event you are directly associated with.
6. Appeal, when you believe the rule was misapplied
The App Review Board hears appeals when you think Apple misunderstood the app or treated you unfairly. Give specific reasons the app complies, answer any open questions first, and file only one appeal per submission.
Checklist before the next submission
- Tested on a device running the latest iOS; no crash on the paths a reviewer will take.
- Demo account in App Review Information works, and the backend is up for the whole review.
- No placeholder text or images; every link works, including support and privacy policy.
- Every in-app purchase is visible and purchasable in this build, or explained in the notes.
- Screenshots show the app in use and match the device types in App Store Connect.
- Review notes describe new features specifically, not generically.
- Account deletion is available inside the app if users can create an account.
- Third-party data sharing, including with third-party AI, is disclosed and consented to.
- If a social login is offered, an equivalent option that meets guideline 4.8 is offered too.
- Purpose strings explain clearly why each permission is needed.
Bug-fix updates are treated differently
If a bug-fix update turns up other issues during review, Apple offers to approve the current submission and let you fix the other issues in the next one, “as long as there are no legal or safety concerns.” You accept by replying to that message in App Store Connect. It is worth knowing when an urgent fix is waiting on an unrelated finding.
Apple also offers 30-minute App Review appointments over Webex to talk through the guidelines and common rejections before you submit.
Questions about App Store rejections
How long does App Store review take?
Apple says 90% of submissions are reviewed in less than 24 hours on average. Incomplete submissions, complex apps and apps repeatedly rejected for the same guideline take longer.
Do I need a new build after a rejection?
Not if the rejection was for metadata only. Apple lets you resubmit the same build after fixing the metadata. Crashes, missing features and code issues need a new build.
What is guideline 2.1?
App Completeness: final versions, no placeholder content, working URLs, a demo account if the app has a login, and working in-app purchases. Apple says over 40% of unresolved issues relate to it.
Where is the Resolution Center?
Messages from App Review are now in the App Review section of the app’s page in App Store Connect. From there, Resolve and then Reply to App Review.
Can I appeal a rejection?
Yes, to the App Review Board, once per submission that did not pass review. Give specific reasons the app complies with the guidelines.
Can you fix an app that keeps getting rejected?
Yes. We start with an audit of the code, the build and the App Store Connect setup against the rejection, then fix and resubmit. We release the apps we run to the App Store from CI.
Next step
30 minutes with an engineer, not a sales rep. You leave knowing what we'd fix first — or that you don't need us.
The first call is free. A code audit of your app is a fixed price from $750, credited against the fix if you continue within 30 days.
Sources
- Apple: App Review Guidelines (last updated June 8, 2026)
- Apple: App Review
- App Store Connect Help: Reply to App Review messages
- Apple: Submit an appeal to the App Review Board
- Apple: Request an expedited review
Checked September 29, 2026.