The 8 Most Common App Store Rejections and How to Fix Them

App Review turns most submissions around in about a day. Get rejected and that day becomes three or four, because you fix, resubmit, and wait again. Passing on the first try is worth real time.

Here are the rejections that come up most often, what triggers them, and what actually fixes them.

1. Guideline 2.1: Incomplete information

The reviewer could not test part of your app.

Usually it means a demo account was missing, the credentials had expired, or a flow needed hardware the reviewer did not have.

Fix: Put working credentials in App Review Information and test them yourself on submission day. If any flow needs explanation, write the steps in the notes field or link a short screen recording.

2. Guideline 2.3: Inaccurate metadata

Your screenshots show something the app does not do.

This catches a lot of teams who ship screenshots designed from mockups. If a screen exists in Figma but not in the build, it cannot appear in your store listing.

Fix: Every screenshot must correspond to a real screen in the submitted build. Remove superlatives you cannot prove, like "number one" or "fastest".

3. Guideline 3.1.1: In-app purchase

You are selling digital content outside Apple's payment system.

Fix: Digital goods and subscriptions go through StoreKit. If you sell physical goods or services consumed in the real world, the rule does not apply, but say so explicitly in your review notes so the reviewer does not have to guess.

4. Guideline 4.2: Minimum functionality

The app is a wrapped website, or does too little to justify being an app.

Fix: Give the app something the browser cannot do: notifications, offline use, camera, widgets, background sync. One real native capability usually clears this.

5. Guideline 5.1.1: Data collection and privacy

Your privacy label does not match what the app actually collects, the privacy policy link is broken, or you ask for a permission you never use.

Fix: Fill the App Privacy questionnaire including what your SDKs collect. Analytics and ad SDKs count as your collection. Open your privacy policy URL before submitting.

6. Guideline 4.3: Spam and duplicates

Several near-identical apps from the same account, often template based.

Fix: Consolidate them, or make each one meaningfully different in function, not just in branding.

7. Guideline 2.5.1: Private APIs

Your build references something Apple does not publish.

Sometimes it is your code, often it is a dependency.

Fix: The rejection names the symbol. Search your dependencies for it and update or replace the offending SDK.

8. Guideline 1.2: User generated content

Your app lets users post content but has no moderation path.

Fix: Apple expects four things: a content filter, a way to report objectionable content, a way to block abusive users, and a published contact method. All four have to exist in the build.

What to do after a rejection

Read the cited guideline before changing anything. The number tells you exactly which rule was applied, and the fix is usually narrower than it first looks.

When you resubmit, describe the change in Resolution Center in one specific sentence. "Removed the external checkout link; subscriptions now go through StoreKit" gets processed faster than "fixed".

If you genuinely believe the rejection was wrong, you can appeal. It works, but only use it when you are sure, because a weak appeal adds days.

A pre-submission list worth keeping

• Demo account tested today
• Every screenshot exists in the build
• Privacy policy URL opens
• Privacy labels cover SDK collection
• Digital purchases go through StoreKit
• Support URL resolves

Six checks, a few minutes, and most of the rejection surface disappears.