App Store rejection reasons: the guidelines that block most apps and how to fix each one

App Store rejection is more common than most first-time developers expect. Apple's 2025 App Store Transparency Report says App Review looked at 9,100,620 submissions last year and rejected 2,093,244 of them, roughly one in four. The same report shows 387,087 submissions approved after an initial rejection, which is the encouraging part: most App Store rejection reasons are fixable, and many are predictable.

This guide goes through the rejection reasons that come up most often, what each guideline actually says, and the fix for each one. It ends with how to reply to App Review, when you can defer a fix, how to appeal, and a checklist to run before you press Submit.

What the numbers say about App Store rejections#

The Transparency Report groups rejections by the five sections of the App Review Guidelines:

Performance is the largest by far, and one guideline dominates it. On its App Review page, Apple says that "on average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more." Start there.

Read the rejection message before you change anything#

Each rejection in App Store Connect names a guideline, such as "Guideline 2.1 - Performance - App Completeness", describes what the reviewer saw, and often includes screenshots or device details. Three things to check before you edit code:

• Which guideline, and which part. "4.3(a)" and "4.3(b)" ask for different fixes.
• Whether it is a question. "Information Needed" rejections often only need a reply with details, not a new build.
• Whether it is eligible for a Bug Fix Submission. If you see "Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update", you can ship the current update now and fix the issue later (see below).

The most common App Store rejection reasons and how to fix them#

1. Crashes and bugs (Guideline 2.1)#

Guideline 2.1(a) says: "We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." Apple asks you to "thoroughly test on devices running the latest software", which right now means iOS 27, and many crashes a reviewer finds only appear on a clean install.

Fix: delete the app and install your release build fresh on a real device running the latest iOS. Test with no network, with permissions denied, and on both iPhone and iPad if you support both, since iPhone apps also run on iPad. Check your crash reports in Xcode Organizer or TestFlight before resubmitting.

2. Missing demo account or review information (Guideline 2.1)#

The guideline asks you to "include demo account info (and turn on your back-end service!) if your app includes a login." A reviewer who cannot get past your sign-in screen has to reject.

Fix: fill in the App Review Information section in App Store Connect with a working username and password, any setup steps, and an explanation of features that need special hardware or a location. If you cannot provide a demo account for legal or security reasons, Apple allows a built-in demo mode, with prior approval. A notes block like this answers most questions up front:

Demo account: [email protected] / Review2026!
The account has sample data so every screen is populated.
Subscriptions: use the sandbox account on the device; the paywall
appears after the 3rd project is created (Projects > +).
Bluetooth scale: not required, tap "Use demo device" on the pairing screen.
New in this version: shared folders (Settings > Sharing).

That last line matters too. Guideline 2.3.1(a) says new features "must be described with specificity in the Notes for Review section" and that "generic descriptions will be rejected."

3. Placeholder content, broken links and missing privacy policy (Guidelines 2.1 and 5.1)#

Apple's list of common issues says: "All links in your app must be functional. A link to user support with up-to-date contact information and a link to your privacy policy is required for all apps." Lorem ipsum, "coming soon" tabs and test images count as placeholder content.

Fix: click every link in the app and in your metadata, including the Support URL and Privacy Policy URL fields. Make sure the privacy policy says what data you collect, how, why, who you share it with, how long you keep it, and how people can ask for deletion.

4. In-app purchase problems (Guidelines 2.1(b) and 3.1.1)#

Guideline 2.1(b) asks that in-app purchases be "complete, up-to-date, visible to the reviewer and functional", and 3.1.1 requires in-app purchase to unlock features or content: "Apps may not use their own mechanisms to unlock content or functionality, such as license keys."

Fix: submit the in-app purchase products with the build, make sure the paywall is reachable in the demo account, add a restore button for restorable purchases, and remove any "enter your license key" flow that unlocks digital features.

5. Vague permission prompts (Guideline 5.1.1(ii))#

Every permission request needs a purpose string in Info.plist, and Apple's purpose string guidance is strict: "A purpose string that only restates the name of the resource, or promises a general benefit without saying what your app actually does, doesn't meet the requirement."

Fix: write one complete, active sentence per resource that names the feature:

<!-- Rejected: restates the resource -->
<key>NSLocationWhenInUseUsageDescription</key>
<string>To use location.</string>

<!-- Accepted: names the feature and the outcome -->
<key>NSLocationWhenInUseUsageDescription</key>
<string>The app uses your location to show trails within 10 km and give turn-by-turn directions.</string>

Two points from Apple's FAQ: purpose strings must be localized for every language you support, and you are responsible for the ones third-party SDKs trigger. If an SDK references an API you do not use, remove it from the binary.

6. No in-app account deletion (Guideline 5.1.1(v))#

If people can create an account in your app, they must be able to delete it there too. Apple's account deletion guidance says "only offering to temporarily deactivate or disable an account is insufficient", and apps outside highly regulated industries "should not require people to make a phone call, send an email, use a chat support flow, or go through other support flows."

Fix: put Delete account in account settings. A confirmation step or a code sent to the account's email is fine. If deletion finishes on your website, link directly to that page. If you use Sign in with Apple, revoke the user's tokens with the REST API.

7. Social login without an equivalent option (Guideline 4.8)#

If you use a third-party login such as Google Sign-In or Facebook Login for the user's primary account, guideline 4.8 requires you to also offer a login service that limits data collection to name and email, lets people keep their email private, and does not collect interactions for advertising without consent. Sign in with Apple meets those terms. The rule does not apply if your app only uses your company's own account system.

8. Screenshots that do not show the app (Guideline 2.3.3)#

Apple's screenshot guidance makes the rule countable: App Review approves only submissions "where more than half of screenshots show the app in use", per device type. Three screenshots need two real screens; four need three. Our guide to App Store screenshot sizes covers the full rule and every accepted pixel size.

Metadata is reviewed too: screenshots, name, subtitle and keywords can each cause a rejection. Photo: Image Hunter / Pexels

9. Not enough functionality or a wrapped website (Guideline 4.2)#

Guideline 4.2 asks for "features, content, and UI that elevate it beyond a repackaged website", and 4.2.2 rules out apps that are mainly "marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Fix: add what the web cannot do well: offline use, notifications people asked for, widgets, App Intents, native sharing, camera or health integrations. In your reply, list the native features and where the reviewer can find them.

10. Spam and duplicate apps (Guideline 4.3)#

Guideline 4.3(a) forbids multiple Bundle IDs of the same app, such as one app per city, team or university; Apple suggests one app with the variations sold through in-app purchase. 4.3(b) covers "apps that are indistinguishable from what's already widely available", naming "dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling" as saturated categories that need "a meaningfully different or improved experience."

Fix: for 4.3(a), merge the variants into one app. For 4.3(b), you have to show what is different, in the app and in your reply. A template app with a new skin rarely gets through.

11. Copycat names, icons and keywords (Guideline 4.1)#

Guideline 4.1(c) says: "You cannot use another developer's icon, brand, or product name in your app's icon or name, without approval from the developer." Apple's copycat guidance extends this to metadata: "Don't include references to popular app names or trademarked terms in any metadata field."

Fix: remove competitor and brand names from the name, subtitle, keyword field and screenshots. If you need keyword ideas that are safe to use, our guide to free ASO keyword research shows how to find them from Apple's and Google's own data.

Most rejections are caught by a ten-minute check before you submit. Photo: Alina Rossoshanska / Pexels

How to respond to an App Store rejection#

Reply first, resubmit second#

Use the App Review page in App Store Connect to reply to the message. If the reviewer misunderstood a feature, explain where to find it, with steps. If you fixed the issue, say what changed and upload the new build. Clear replies often resolve "Information Needed" rejections without a new binary.

Use a Bug Fix Submission when you can#

If an update to an already-approved app is rejected for something with no legal or safety concern, Apple may offer a Bug Fix Submission. Reply that you want the current submission approved and will fix the issue next time, and do not resubmit, because "it will trigger a new review." Deferred issues cannot be deferred twice.

Appeal only when you believe the app complies#

The App Review Board handles appeals when you believe your app follows the guidelines. Reply to the rejection first. If that does not resolve it, file one appeal per app, cite each guideline and explain "point by point" how the app meets it. Do not use an appeal to ask for status updates or a faster review.

Ask for an expedited review when it is genuinely urgent#

App Review aims to review at least 50% of submissions in under 24 hours and 90% in under 48. For a critical bug fix or a date-bound event, you can request an expedited review after submitting, with the reason in the Notes field. Our guide to App Store review time covers how long reviews take in practice and how to plan a launch date around them.

Talk to App Review before you submit#

If you are unsure how a guideline applies, you can request a 30-minute App Review appointment over Webex, on Tuesdays and Thursdays during your local business hours. Apple is clear that the appointment cannot preapprove an app, but it is a good way to avoid a 4.2 or 4.3 surprise on a new concept.

Pre-submission checklist#

• Release build installed fresh on a real device with the latest iOS, on iPhone and iPad.
• No placeholder text, test images or empty tabs.
• Demo account works, the back end is live, and review notes explain hardware or location needs.
• New features described specifically in Notes for Review.
• Support URL and privacy policy link work, in the app and in metadata.
• In-app purchases submitted, reachable and restorable; no license-key unlocks.
• Every permission has a specific, localized purpose string, including those triggered by SDKs.
• In-app account deletion if the app creates accounts.
• An equivalent privacy-friendly login offered next to any third-party social login.
• More than half of the screenshots per device show the app in use.
• No competitor names or trademarks in the name, subtitle, keywords or screenshots.
• The app offers something a website or an existing app category does not.

After approval: make sure people can find the app#

Approval is only the start. A new app has no ratings, no search history and no chart position, so its first weeks decide a lot. Our guide on how to get featured on the App Store covers the nomination form most developers never open, and the launch-week visibility checklist covers the links and communities you control. If the app does not show up in search a few days after release, work through why an app is not showing in App Store search.

There is also one ranking you do not have to wait for. On AppRanker, an iOS app's place on the app leaderboard is a plain sort on what each listing has paid, with no review queue and no account, and every row links straight to your App Store page. Once you are approved, paste your App Store link on the AppRanker home page to see what each position costs before you pay.

FAQ#

What is the most common reason for App Store rejection?#

Guideline 2.1, App Completeness. Apple says over 40% of unresolved issues relate to it, covering crashes, bugs, placeholder content, broken links and missing review information such as a demo account. In the 2025 Transparency Report, the Performance section, which includes 2.1, accounted for 1,354,418 rejections.

How long does App Store review take after a rejection?#

A resubmission goes back into the normal queue. Apple aims to review at least 50% of submissions in under 24 hours and 90% in under 48 hours. For a critical bug fix or an event deadline, you can request an expedited review after submitting.

Can I appeal an App Store rejection?#

Yes. Reply to the rejection in App Store Connect first. If that does not resolve it, file one appeal per app with the App Review Board, citing each guideline involved and explaining point by point how your app meets it.

What does Guideline 4.3 spam mean?#

Guideline 4.3(a) covers multiple Bundle IDs of what is essentially the same app, such as one per city. Guideline 4.3(b) covers apps indistinguishable from what is already widely available, with categories such as flashlight, wallpaper and simple timer apps needing a meaningfully different experience to be accepted.

Do I need to resubmit the build to answer an App Review question?#

Not always. If the rejection asks for information, or the reviewer missed a feature, reply in App Store Connect with the details. Upload a new build only when you have changed the app.

Image credits#

• Cover, person coding on a MacBook Pro: photo by Olia Danilevich on Pexels, Pexels License. Cropped to 1200x630.
• App Store icon with a notification badge on an iPhone: photo by Image Hunter on Pexels, Pexels License. Resized.
• Handwritten checklist: photo by Alina Rossoshanska on Pexels, Pexels License. Resized.