Common App Store rejection reasons and how to fix each one

You built the app, paid the $99, hit Submit for Review and got back a message that starts with "Guideline 2.1" and ends with no clear instruction. That is normal. One r/iOSProgramming post titled "Got rejected by the App Store 5 times before getting approved" ranks first on Google for this exact search, which tells you how many people are in the same spot.

The good news: first time rejections cluster around the same handful of guidelines, and almost all of them are fixable in an afternoon. The bad news: each rejection costs you another review cycle, so the cheapest fix is the one you make before you submit.

This guide lists the guidelines that trip first time submitters most, in plain words, with the exact fix for each and the order to check them in.

What are the most common App Store rejection reasons?

The most common rejection is Guideline 2.1 App Completeness, which Apple says accounts for over 40% of unresolved issues. After that, first time indie apps mostly get stopped by subscription disclosure (3.1.2), privacy and account deletion (5.1.1), login rules (4.8), inaccurate metadata (2.3), thin apps (4.2) and copycat apps (4.3).

A quick definition: a rejection means App Review found a problem with a specific submission. It is not a ban. You fix it and resubmit, reply with information, or appeal. The review notes are the free text box in App Store Connect where you tell the reviewer how to use your app; most rejections below are partly a review notes problem.

The "how often" column is our reading of developer reports on Reddit, not an Apple figure; only the 40% for 2.1 comes from Apple.

Guideline 2.1: why does Apple say my app is incomplete?

Apple rejects under 2.1 when the build crashes, shows placeholder content, has broken links, or the reviewer cannot reach the features. The guideline asks you to "include demo account info (and turn on your back-end service!) if your app includes a login."

The traps first time submitters hit:

• The reviewer used an iPad. In the top r/iOSProgramming thread, the poster was rejected twice for the same onboarding bug, the second time on iPad even though the app was iPhone only. Commenters were blunt: reviewers routinely test on iPads, where iPhone apps run in compatibility mode. One suggested testing on an iPad mini simulator specifically.
• The backend was asleep. Free tier servers that spin down, a staging database, or an API key that expired the day after you submitted.
• No demo account, or one that does not work. If signing up requires a phone code or an email link, the reviewer will not do it. Give them credentials that already work.
• In-app purchases the reviewer cannot find. Guideline 2.1(b) says purchases must be "visible to the reviewer and functional." If a purchase only appears after day three, say so in the notes.

Watch out: a newer flavour of 2.1 is "Information Needed", where the app is stopped before anyone tests it. In an r/iOSDevelopment thread about it, the most useful reply was to keep a short screen recording of the main flow ready, because once reviewers see a demo the app usually goes through.

Guideline 3.1.2: why was my subscription rejected?

Apple rejects subscriptions when the paywall does not clearly state what the user gets, the price and billing period, and links to your terms and privacy policy. The guideline says that before asking someone to subscribe, "you should clearly describe what the user will get for the price."

One r/AppBusiness developer listed this as their first of three rejections: no Terms of Use link, incomplete subscription details and a Restore Purchases button that was hard to find. Their fix was all three:

1. Show the full price and period in the largest text on the paywall ("$29.99 per year"), not just a per week equivalent.
2. If there is a free trial, say exactly when billing starts.
3. Add tappable Terms of Use (EULA) and Privacy Policy links on the paywall itself.
4. Put the same two links in the App Store description or the EULA field in App Store Connect.
5. Make Restore Purchases a visible button, not a hidden gesture.

Our guide to RevenueCat paywall best practices covers paywall layouts that convert without tripping review.

Guideline 5.1.1: privacy policy and account deletion

You need a privacy policy linked both in App Store Connect and inside the app, purpose strings that explain each permission, and, if users can create an account, a way to delete it inside the app. Guideline 5.1.1(v) is direct: "If your app supports account creation, you must also offer account deletion within the app."

What gets beginners rejected:

• The privacy policy is a generic template that does not mention the analytics or crash SDKs you added.
• Permission prompts say "This app needs your camera" instead of why ("to scan receipts you want to save").
• Account deletion is an email address in the FAQ. Put a Delete account row on the profile or settings screen that actually deletes the account.
• The privacy "nutrition label" in App Store Connect does not match what your SDKs collect.

Login rules: guideline 4.8 and forced sign in

If you use Google or another third party login for the main account, Guideline 4.8 says you must also offer an equivalent login that limits data to name and email and lets people hide their email; Sign in with Apple meets that. Separately, 5.1.1(v) says that if your app "doesn't include significant account-based features, let people use it without a login."

The r/AppBusiness developer above was rejected for login even with Google and Apple sign in, and fixed it by adding guest access. The lesson for a simple utility: do not put a sign in wall in front of features that do not need an account.

Guidelines 2.3, 4.2 and 3.1.1: metadata, thin apps and payments

These three catch apps whose listing promises more than the build delivers, apps that are basically a website, and apps that unlock features without Apple's in-app purchase.

2.3 Accurate Metadata

Your screenshots, description and preview must "accurately reflect the app's core experience." Mockups of features you plan for version 2, competitor names in your keywords, or "number 1 rated" claims are easy rejections.

4.2 Minimum Functionality

Apple wants "features, content, and UI that elevate it beyond a repackaged website." A web view wrapper with a login is the classic case. Add something native that lasts: offline use, widgets, notifications that matter, on device features.

3.1.1 In-App Purchase

If a digital feature is unlocked inside the app, it must go through in-app purchase. License keys, QR codes and a "pay on our website" button for premium features are listed as not allowed.

Guideline 4.3 spam: the one that scares AI built apps

A 4.3 rejection means Apple thinks your app duplicates what is already widely available or duplicates your own other apps. Guideline 4.3(b) names categories such as dating, flashlight, sound effects, wallpaper, simple timers and fortune telling where Apple "will not accept new submissions unless they offer a meaningfully different or improved experience."

In an r/iosdev thread from a developer who vibe coded a Flutter app and was rejected twice under 4.3(a), replies pointed at three likely causes: listing metadata stuffed with the same keywords as every competitor, template and package residue that makes the build look like other recent submissions, and a first few minutes of use that look like a clone. Some replies were harsh, but the practical advice holds:

1. Rewrite the name, subtitle, screenshots and description around one specific user and problem.
2. Strip starter template screens, sample assets and default names from the project.
3. Make the unique feature visible in the first minute, and say where it is in the review notes.
4. If rejected again, ask for a phone call with App Review and frame the reply as an unmet user need. One r/iOSProgramming commenter said explaining "users in this situation currently have no way to do Y" landed better than a feature comparison.

Resubmitting near identical builds under 4.3 is risky: Apple warns that repeated low effort submissions "may lead to removal from the Apple Developer Program." The App Store Apps pack teaches picking a niche from real one star reviews of category leaders, which also gives you the differentiation story reviewers want.

Should you reply, resubmit or appeal?

Reply when the reviewer misunderstood or asked for information, resubmit when the fix needs a new build, and appeal only when you believe the decision is wrong.

The poster of the top r/iOSProgramming thread advised replying instead of resubmitting to clarify, because a resubmission can go to a different reviewer. A commenter disagreed, saying a new build had always been faster for them. Both are real experiences; reply first and resubmit if nothing moves after a couple of days.

Mistakes first time submitters make

These come straight from the Reddit threads behind this guide:

• Testing only on your own iPhone. Run the release build on an iPad simulator, a small iPhone and with a fresh install.
• Empty review notes. One r/iOSProgramming commenter called them important because they point the reviewer to what is different and to where paywall features live.
• Assuming the rejection email is complete. Several developers said each new reviewer raised a new issue; one lost about 20 days over four rounds. Fix everything on the checklist, not just the line you were cited for.
• Treating the first review like an update. An r/AppBusiness commenter noted the first submission of a new app is reviewed more strictly than later updates.
• Pushing a half finished build to "get in the queue". Every rejection is a new cycle of up to two days, plus your response time.

Pre-submission checklist

Run this before you press Submit:

1. Fresh install of the release build on an iPad simulator and a small iPhone, no crashes, no placeholder text.
2. Backend live, API keys valid for at least two weeks.
3. Demo account with sample data, credentials in the review notes.
4. Review notes: what the app does in two sentences, where the paywall and each purchase appear, anything non obvious.
5. Paywall: full price and period, trial terms, Restore Purchases, Terms and Privacy links.
6. Privacy policy linked in App Store Connect and in the app, permission strings that explain why.
7. Delete account inside the app if accounts exist; Sign in with Apple if you offer social login.
8. Screenshots and description match the build exactly.
9. Name, subtitle and keywords that are yours, not a copy of the top competitor.

If you have not set up the account yet, read how much it costs to publish an app on the App Store and individual vs organization developer accounts first, since the account type changes the seller name on your listing.

Where to go from here

1. Read the rejection and map it to the table above.
2. Fix that item and every other item on the checklist in the same pass.
3. Reply with a screen recording if it was a misunderstanding, otherwise submit the new build with detailed review notes.
4. If you still disagree after a second round, request a call or appeal to the App Review Board.

Approval is only the start; nobody can promise downloads or income after it. The App Store Apps pack adds the full step by step: picking a niche that passes 4.3, listing and paywall templates, launch checklists and the pricing lessons, across 24 lessons in 6 modules, and all 16 Money Printer packs are $39 together.