Apple App Rejection: Why Your App Got Rejected (5 Real Cases)

An Apple rejection almost always comes with a specific reason, written in the review message: a numbered guideline, often with a screenshot attached. The most common reasons for a first app are an app that isn't finished (2.1), privacy that's declared wrong (5.1.1), misleading metadata (2.3.2), a payment that bypasses in-app purchase (3.1.1) or a rating request in the wrong place (5.6.3). In the vast majority of cases, the reviewer understood your app just fine: it's your submission that left an opening.

I know this because I've taken these rejections myself. I publish my own iOS apps: Solys (an alarm clock with mini-games) and TradaZen (a trading simulator) are on the App Store. Solys got rejected twice, once before launch and once on an update, and two other apps, Clic and Nolera, were rejected, fixed and resubmitted to Apple. Here are the five rejections and their real cause, then the method for replying and the checklist I run before every submission.

Why Apple rejects an app: the 5 rejections I got

2.1 rejection on Solys: the demo was impossible to win

Solys's onboarding includes a playable demo: you have to win a mini-game, just like when the alarm goes off. On my phones, everything worked. The reviewer, though, was testing on an iPad, where an iPhone app runs in compatibility mode in a smaller window. At that size, the gap left for the bird in the mini-game became narrower than the bird itself, and the "Continue" button only lit up if you won. Apple asked for a way to skip the game mission.

The fix: a demo whose geometry is calculated from the actual screen size, and a link to skip the demo if you fail.

The lesson: every required step needs a way out, and every required screen gets tested on the smallest possible format before each submission.

5.6.3 rejection on Solys: the rating request during onboarding

Second rejection, on the next update. Apple wrote that the app asked for a rating on first launch or during onboarding. The rating screen showed up right after the demo, before the user had experienced anything in the app.

The fix: the request moved to the end of the flow, and it only shows if the user just won the demo.

The lesson: every sensitive request (rating, notifications, subscription, tracking) comes after proof of value, never before.

5.1.1 rejection on Clic: the online privacy policy was out of date

Clic generates content with AI, and the app did have its consent screen. The problem was elsewhere: the privacy policy published on the website was the old version, and it didn't describe everything the app collects.

The fix: full policy published, English summary added, review notes updated.

The lesson: Apple reads your policy online, not the one sitting in your repo. Before every submission, open the URL you declared and check that it says what your app does.

5.1.1 rejection on Nolera: an "Allow" button before the system prompt

Before iOS's actual camera access prompt, Nolera showed an explainer screen with an "Allow" button. For Apple, that label pushes users to accept before the official system prompt.

The fix: the button now says "Continue", in all 8 of the app's languages.

The lesson: a screen that sets up a permission explains, it doesn't decide for the user. Apple's recommendations are in its privacy design guidelines.

2.3.2 rejection on Nolera: the icon reused as a promotional image

Subscriptions can have a promotional image in App Store Connect. On two of Nolera's subscriptions, it was just the app icon. Apple ruled it non-compliant.

The fix: the images were removed from both subscriptions, and the submission was recreated.

The lesson: every element of your listing gets reviewed, including the ones you fill in without thinking, like the age rating.

Which guidelines come up most often?

All the rules are in the App Review Guidelines. The ones that trip up first apps most often:

2.1: App Completeness. The app crashes, a button leads nowhere, a required screen doesn't work on some format. If your app requires sign-in, provide a demo account in the review notes, otherwise the reviewer gets stuck on the login screen. Everything you need to know about this one is in my guide to guideline 2.1.

2.3: Metadata. Screenshots that don't show the real app, a description promising a feature that isn't there, non-compliant promotional images.

3.1.1: In-App Purchase. To unlock digital content or features in the app, the general rule is Apple's in-app purchase. Exceptions depend on the country and keep changing: read the current version of the guidelines before planning another payment method. The full picture is on the iOS in-app subscriptions page.

3.1.2: Subscriptions. A subscription app has to clearly show what the user gets and at what price. The classic paywall mistakes are in iOS paywall: 7 beginner mistakes.

4.3: Spam. The app looks like a thousand others or doesn't offer enough on its own. It's the hardest rejection to fix: you prevent it when you pick your idea. I explain it in detail in the guide to guideline 4.3.

5.1.1: Privacy. Data collection disclosures that don't match what the app actually does, an incomplete privacy policy, a permission requested without a clear explanation.

How do you reply to an Apple rejection without losing days?

A rejection isn't a verdict, it's a back-and-forth. The process that works:

1. Read the reason twice. The message cites the guideline and often attaches a screenshot. Lots of developers reply off-target because they read too fast.
2. Find the real cause. On both Clic and Nolera, the real cause wasn't what the text seemed to suggest at first. Reproduce the problem under the reviewer's conditions: same kind of device, fresh account, first launch.
3. Fix the reason, nothing else. This isn't the time to add three features: every change widens what gets reviewed.
4. Reply in App Store Connect. Explain in two factual sentences what you fixed, by replying to the App Review message.
5. Appeal only if you're sure. Apple lets you go to the App Review Board if you think your app was misunderstood, with one appeal per rejected submission. Contesting a deserved rejection just wastes time.

On timing, Apple says it reviews at least 50% of submissions in under 24 hours, and 90% in under 48 hours. It's rejections that stretch your schedule, not the queue: details are in App Store review time. The full process after a rejection is on the app rejected by Apple page.

An avoidable rejection costs you a full review cycle. The best answer to Apple is a submission that gives it nothing to object to.

The checklist I run before every submission

Built one rejection at a time, on my own apps:

• Every required screen tested on the smallest iPhone, the largest, and on iPad in compatibility mode, following the grid from guideline 4.0 design
• A way out of every onboarding step, even if the user fails
• Demo account in the review notes if the app has sign-in
• Purchases tested in sandbox, including restore
• Price, duration and links to terms and privacy shown where Apple requires them, in every language
• Online privacy policy reread on submission day
• Privacy disclosures matching what the app really collects, privacy manifest included
• Pre-permission screens without an "Allow" button
• Rating and notification requests placed after proof of value, without unlocking anything in exchange for a rating (guideline 3.2.2)
• Promotional images and screenshots that show the real app, including on your custom product pages

If this is your first release, the publish an app on the App Store page covers every step before submission.

A template to explain your flow to App Review

Download the App Review notes template: instructions in French, notes in English to fill in, and an outline for replying to a rejection. It makes you spell out the version, the path through the screens and the expected result. Only keep what actually exists in your build.

Replace "the app saves correctly" with a reproducible scenario: starting screen, action, close and relaunch, result found again. After a rejection, cite the fixed behavior and the device you checked it on. If you couldn't reproduce the problem, explain what's missing to reproduce it.

Demo account credentials go in the dedicated fields in App Store Connect, never in a public file. You can prepare your evidence with the TestFlight testing grid and find the five free templates.

Avoid these rejections before you submit

The Apple Review Kit bundles my pre-submission checklist, my fixed Apple rejections and Claude Code skills that review your project, your paywall and your listing before you submit.

Already rejected? The kit helps you find the cited rule, what it requires, and an example fix and reply. If you want us to go over your case together right now, book an hour with me over video.

Nobody can guarantee Apple will accept your app. Starting from rejections someone has already been through just lowers the odds of getting caught by the same ones.

Haven't submitted your app yet? The free diagnostic sends you my Apple anti-rejection checklist and tells you what's left to do. If you're still building it, the home page shows how to create a mobile app with these rejections in mind.

Frequently asked questions

Why is my app being rejected by Apple?

Almost always for a specific reason, written in the review message: a numbered guideline, often with a screenshot attached. For a first app, the most common reasons are an app that isn't finished (2.1), privacy that's declared wrong (5.1.1) and misleading metadata (2.3.2). There's also a payment that bypasses in-app purchase (3.1.1) and a rating request in the wrong place (5.6.3).

Why is my app rejected when it works on my iPhone?

Because the reviewer may test under different conditions than yours. On Solys, my alarm clock with mini-games, they tested on an iPad, where an iPhone app runs in compatibility mode in a smaller window. There, the demo was impossible to win. The fix: a demo calculated from the actual screen size, and a link to skip it if you fail.

What should I do when Apple rejects my app?

Read the reason twice, then find the real cause by reproducing the problem under the reviewer's conditions: same kind of device, fresh account, first launch. Fix that reason and nothing else, because every change widens what gets reviewed. Then reply in App Store Connect with two factual sentences about what you fixed.

Can you contest an Apple rejection?

Yes, but only if you're sure of your case. Apple lets you go to the App Review Board if you think your app was misunderstood, with one appeal per rejected submission. Contesting a deserved rejection just wastes time. Otherwise, fix the reason and reply in App Store Connect.

Does a rejection delay publication?

Yes. Apple says it reviews at least 50% of submissions in under 24 hours, and 90% in under 48 hours: so it's rejections that stretch your schedule, not the queue. An avoidable rejection costs you a full review cycle. Details on timing are in App Store review time.

What should I check before submitting an app to Apple?

Test every required screen on the smallest iPhone, the largest and an iPad in compatibility mode, then test purchases in sandbox, including restore. Reread your online privacy policy on submission day and provide a demo account in the review notes if the app has sign-in. This checklist was built one rejection at a time, on my own apps.