App Store Rejection: Why Apps Get Rejected and How to Avoid It

You finished the app. You paid for the developer account, filled in the listing, pressed submit, and waited. Then the email arrived: your submission was rejected. For a first-time founder, an App Store rejection feels like a verdict on the whole project. It almost never is.

Rejection is routine. In its own transparency report, Apple says it reviewed about 7.8 million app submissions in 2024 and rejected about 1.9 million of them. That is roughly one in four. Plenty of those were spam and fraud, but plenty were ordinary apps from ordinary teams that missed something fixable. Most of the reasons an app gets rejected are predictable, and almost all of them can be caught before you submit.

This guide covers what review actually checks, the handful of reasons behind most rejections, and a routine that makes your first submission boring in the best way.

What app review actually checks

It helps to know what you are up against. On Apple's side, a human reviewer installs your app on a real device, usually works through it for a few minutes, and compares what they see against the App Review Guidelines. Automated checks run alongside this for things like private APIs and malware.

The reviewer is not judging whether your idea is good. They are checking roughly four things:

• Does it work? No crashes, no dead buttons, no placeholder screens.
• Is it honest? The listing matches the app, the screenshots show the real product, and the description does not promise what is not there.
• Does it respect users? Privacy disclosures are accurate, accounts can be deleted, and data collection is explained.
• Does it follow the money rules? Digital goods and subscriptions go through in-app purchase where required.

Google Play works differently. Much of its review is automated, and its biggest hurdle for new founders comes before review even starts, which we will get to.

The five reasons behind most App Store rejections

1. The app is broken or unfinished

Apple's report puts performance as the largest rejection category by far. In 2022, the year it first broke the numbers down, more than a million submissions were flagged under performance, which covers crashes, bugs, and incomplete apps. This is the guideline Apple calls App Completeness.

The usual causes are not dramatic. A login that fails on a fresh install. A screen that still says "coming soon." A button that does nothing on an older iPhone. A feature that only works with data the reviewer does not have.

The fix is mostly about testing the way the reviewer will: a clean install, on a real device you did not develop on, with a brand new account. If your app requires a login, give the reviewer a working demo account in the review notes. A missing or broken demo login is one of the most common and most avoidable reasons apps get rejected.

2. The listing does not match the app

Metadata rejections happen when your screenshots, description, or keywords do not reflect what the app actually does. Showing a feature that is not built yet, using screenshots from a design mockup, or mentioning other platforms ("also on Android!") in your description can all trigger one.

Treat your listing like a contract. Every claim in it should be something the reviewer can find in the app within a couple of minutes.

3. Privacy is missing or inaccurate

Privacy is now a core part of review. Apple expects a privacy policy link, privacy "nutrition label" answers that match what your app and its third-party tools actually collect, a clear reason shown whenever you ask for permissions like camera, location, or contacts, and, if users can create an account, a way to delete that account from inside the app.

Non-technical founders get caught here because they do not know what their own app collects. Analytics tools, crash reporters, and ad networks all collect data on your behalf, and you are responsible for declaring it. Ask your developer for a written list of every third-party service in the app and what each one collects, then answer the privacy questions from that list.

4. Payments go around in-app purchase

If your app sells digital content, features, or subscriptions to users, Apple generally requires that you use its in-app purchase system, and Google has similar rules. Linking out to your website to pay, or unlocking premium features through a payment flow Apple cannot see, is a fast route to rejection. The rules around external payment links have been loosening in some regions after legal challenges, but they vary by country and keep changing, so check the current guidelines rather than assuming.

Physical goods and real-world services, like a booked session with a coach or a product shipped to a door, are different and can use normal payment processors. If your app mixes both, decide early which parts are digital, because it changes your pricing and your build.

Also make sure subscription terms are clear on the paywall: what the user gets, the price, the billing period, and how to cancel. Vague paywalls get rejected often.

5. The app does not do enough

Apple rejects apps that are "not useful, unique, or app-like enough." This catches apps that are just a website in a wrapper, apps with one thin feature, and apps that look nearly identical to many others already in the store. Template-built apps and apps generated with AI tools increasingly run into this, because they can end up looking like thousands of other submissions.

The defense is a clear core action that works natively and well. Your first version does not need many features, but the one it has should feel like an app, not a bookmark. If your concept really is mostly content, consider whether a web app is the honest first step.

Google Play's hurdle is testing, not review

Google Play review rejects apps for many of the same reasons, especially privacy declarations and policy issues. But the surprise for most new founders is earlier in the process.

If you open a new personal developer account, Google requires a closed test before you can publish to everyone: at least 12 testers who stay opted in for at least 14 consecutive days. Only then can you apply for production access. Organization accounts have different requirements, so check which type you have before planning your launch date.

This is not a formality you can rush. Recruit your testers before you need them, ideally from your waitlist or audience, and start the clock as soon as you have a stable build. Founders who discover this rule the week they planned to launch lose two weeks or more.

A pre-submission routine that catches most problems

Run through this before every first submission. It takes an afternoon and saves days of back and forth.

1. Fresh install test. Delete the app, install it from TestFlight or the internal track, and create a brand new account. Go through every screen. 2. Old device test. Try it on the oldest phone you plan to support, and on a small screen. 3. Offline and bad network test. Turn on airplane mode mid-session. The app should show a sensible message, not crash. 4. Demo account. Create a reviewer login with realistic data already in it, and put the credentials in the review notes. 5. Review notes. Explain in plain language what the app does, how to reach the main feature, and anything non-obvious, like a feature that needs a physical item or a specific location. 6. Listing audit. Compare every screenshot and sentence in your description against the real app. 7. Privacy audit. Check that the policy link works, the privacy answers match your third-party services, permission prompts explain why, and account deletion is reachable in the app. 8. Paywall audit. Price, period, what is included, and how to cancel, all visible before purchase, with restore purchases available.

What to do when you get rejected anyway

Even with good preparation, a first app can still get rejected. Here is how to handle it.

Read the exact guideline cited. The rejection message names a guideline number and usually includes a screenshot or a note. Look up that guideline and read it fully before you change anything.

Fix the specific issue, then reply. If the problem is clear, fix it, resubmit, and use the reply in App Store Connect to explain briefly what changed. Resubmissions are usually reviewed faster than the first submission.

Ask when it is unclear. If you do not understand the rejection, reply and ask the reviewer for clarification. Polite, specific questions often get useful answers. If you believe the reviewer made a mistake, Apple has a formal appeal process through the App Review Board.

Do not argue the idea. Reviewers respond to evidence about how the app behaves, not to explanations of how important the app is. Show, do not plead.

Apple's own numbers show that a large share of rejected apps are later approved after fixes. A rejection is a to-do list, not a ruling.

The real lesson

Most rejections come from the gap between how the app works for the people who built it and how it works for a stranger seeing it for the first time. The reviewer is that stranger. If you test like a stranger, describe the app honestly, know what data you collect, and follow the payment rules, your App Store rejection risk drops to something close to luck.

Plan for one round of feedback anyway. Build a few days of slack into your launch date, and never announce a launch day before the app is approved.