Why did Apple reject my app? The common App Store rejections, and how to fix them

You submitted your app, waited, and got the email: your submission “did not pass review”, followed by a guideline number that means nothing to you yet.

First thing: this is normal. Apple’s own 2025 transparency report says it reviewed 9.1 million app submissions and rejected 2.09 million of them — roughly one in four. It also says 387,000 submissions were approved after an earlier rejection. A rejection isn’t Apple deciding your app doesn’t belong. It’s a list of things to fix.

Here’s what the common ones actually mean, and what to do about each.

How to read your rejection

The rejection lives in App Store Connect, on your app’s page, as a message from App Review. It names one or more guidelines by number — “Guideline 2.1 – Performance – App Completeness” — and then, crucially, explains what the reviewer actually saw. Often there’s a screenshot.

Read the explanation, not just the number. The number tells you the category; the explanation tells you the fix. And if the explanation doesn’t make sense, the prompt further down this page decodes it for you.

The App Store rejections you’re most likely to see

Apple groups its guidelines into five sections — Performance, Legal, Design, Business and Safety — and Performance accounts for more rejections than the other four put together. Within it, one guideline dominates: Apple says over 40% of unresolved issues are related to Guideline 2.1.

Guideline 2.1 – App Completeness

The big one. It covers anything that makes your app look unfinished to the reviewer:

• Crashes and bugs. The reviewer runs your app on a current device and iOS version. If it crashes on launch or a button does nothing, it’s rejected. Test on a real device, on the latest iOS, before you submit.
• Placeholder content. Lorem ipsum, “coming soon” screens, test data, an empty feed. Apple’s line is blunt: items with placeholder content “are not ready to be distributed”.
• Broken links. Every link has to work — and you need a working support link and a privacy policy link.
• No way in. If your app needs a login, you must give the reviewer a demo account that works, with any data they need to see the features. This is behind most “Guideline 2.1 – Information Needed” messages, which aren’t a rejection of the app so much as the reviewer asking for help. Reply with what they asked for.

Turn your backend on, too. Apple’s guidelines literally say it: include demo account info “(and turn on your back-end service!)”. A reviewer who can’t sign in because a free database has gone to sleep will reject you.

Guideline 2.3 – Accurate Metadata

Your listing has to match your app. The usual causes:

• Screenshots that don’t show the app in use. Apple’s guideline says screenshots “should show the app in use, and not merely the title art, login page, or splash screen.”
• A description promising features the app doesn’t have — including “coming soon” ones.
• Mentions of other platforms, like “also on Android”, in your listing.

Guideline 4.2 – Minimum Functionality

The one that catches web apps. Apple says your app should include “features, content, and UI that elevate it beyond a repackaged website”, and that if it isn’t “particularly useful, unique, or ‘app-like’, it doesn’t belong on the App Store.”

If you’ve wrapped a website in a native shell — with Capacitor, Cordova or a wrapper service — this is the rejection you’re most at risk of. Adding a couple of native features sometimes gets you over the line, but the reliable fix is a real mobile app. I’ve written up how to do that from a Lovable project in how to turn your Lovable app into a real mobile app, and the same approach works for most web apps.

Guideline 4.3 – Spam

Apple rejects apps that are “indistinguishable from what’s already widely available”, and multiple copies of the same app under different names. If your app came from a template, make sure it’s genuinely yours — your own content, your own design, your own reason to exist.

Guideline 4.8 – Login Services

If people sign in to your app with Google, Facebook or another third-party login, you must also offer an equivalent option that limits data collection to name and email, lets people keep their email address private, and doesn’t track them for advertising without consent. Sign in with Apple ticks all three, which is why it’s the standard fix. If your app only uses its own email-and-password sign-in, this guideline doesn’t apply.

Guideline 5.1.1 – Data Collection and Storage

Privacy is the other big source of rejections, and 5.1.1 has several parts people trip on:

• A privacy policy, linked in two places: in App Store Connect and inside the app, somewhere easy to find. It has to say what you collect, how, what for, and how people can have their data deleted.
• Clear permission messages. When your app asks for the camera, location or photos, the message has to say specifically why. “This app needs access to your camera” isn’t enough; “Scan a barcode to log a food” is.
• Account deletion — Guideline 5.1.1(v). If people can create an account in your app, they must be able to delete it in the app. An email address to write to doesn’t count. This one rejects a lot of first submissions.
• Don’t force a login you don’t need. If your app doesn’t have significant account-based features, Apple wants people to be able to use it without signing in.

Guideline 3.1.1 – In-App Purchase

If you charge for anything digital inside your app — subscriptions, premium features, credits, unlocked content — it has to go through Apple’s in-app purchase. A “buy on our website” button or your own payment form for digital content will be rejected. Physical goods and real-world services (food delivery, a haircut) are different and can use ordinary payments.

What to do when you’re rejected

1. Read the whole message, and look at any screenshot attached. Work out exactly what the reviewer saw.
2. Fix the specific thing. Not the general area — the thing they named.
3. Reply to App Review in App Store Connect, saying what you changed. If they asked a question, answer it plainly. If the issue was something they couldn’t reach, tell them exactly how to reach it.
4. Resubmit the fixed build for review.
5. Appeal only if they’ve got it wrong. If you believe the reviewer misunderstood your app, you can appeal to the App Review Board. Apple asks for specific reasons your app complies, one appeal per submission, and any outstanding questions answered first. Appealing a rejection that’s actually right just costs you time.

This prompt does the decoding — paste in your rejection and it tells you what it means, what to change, and drafts your reply:

My iOS app was rejected by Apple's App Review. I'll paste the rejection message below. I'm not a developer, so explain everything in plain English.

1. Tell me which guideline or guidelines it cites, and what each one means in plain English.
2. Explain what the reviewer most likely saw or did that triggered it.
3. Give me a specific list of what to change in my app, my App Store Connect listing, or my App Review notes to fix it. If the fix needs code changes, say what kind, so I can ask my developer or AI coding assistant.
4. Tell me whether this looks like a correct rejection I should fix, or a misunderstanding worth explaining or appealing to the App Review Board — and why.
5. Draft a short, polite reply to App Review for App Store Connect, saying what I've changed (leave placeholders where I need to fill in details).

Here's the rejection:
[Paste the full rejection message here]

How to avoid an App Store rejection in the first place

Most rejections are predictable, which means most are avoidable. Before you submit:

• Test the exact build you’re submitting, on a real iPhone, on the latest iOS, from a fresh install.
• Give the reviewer a demo account that works, with real-looking data, in the App Review notes — plus anything they’d need to reach every feature.
• Hunt down placeholder content: every screen, every empty state, every “coming soon”.
• Check every link, including your support and privacy policy links.
• Add in-app account deletion if people can create accounts.
• Rewrite your permission messages so each one says specifically why.
• Make your screenshots show the app in use.
• Offer Sign in with Apple if you use Google or another social login.

If your app is built with an AI coding agent, it can do most of that checking for you. Run this in your app’s folder before every first submission:

I'm about to submit this app to Apple's App Store for the first time. Review the codebase for the most common App Store rejection reasons and give me a report. Don't change any code — just report, in plain English, because I'm not a developer.

Check for:
1. Guideline 2.1: placeholder or test content, "coming soon" screens, lorem ipsum, debug menus, hard-coded test data, and anything that could crash on launch.
2. Guideline 5.1.1(v): if users can create an account, is there a way to delete the account from inside the app? Where?
3. Guideline 4.8: if the app offers Google, Facebook or another third-party sign-in, does it also offer Sign in with Apple?
4. Guideline 5.1.1: list every permission the app requests (camera, photos, location, contacts, microphone, notifications, tracking) with its permission message, and flag any message that doesn't say specifically why.
5. Privacy and support: is there a link to a privacy policy and a support page inside the app?
6. Guideline 3.1.1: does the app sell anything digital without Apple's in-app purchase, or link out to a website to pay?
7. Anything else you'd expect an App Store reviewer to flag.

For each item, say "OK", "Risk" or "Will be rejected", where in the code you found it, and what to change.