App Store rejection: why it happens and how to fix it

An App Store rejection isn’t a verdict, it’s a letter with notes. Apple reviews every build by hand, and in a few minutes the reviewer tries to do what a new user would: install, open, sign in, tap everything, and find out where the app stops making sense.

Apps built with Cursor, Claude Code, Bolt or Lovable get rejected for the same things as everyone else. They just hit those things more often: AI builds what works in a demo and rarely thinks about a person seeing the app for the first time, on a clean phone.

Crashes and the clean install

The most common reason is that the app crashes or hangs. It works for you because your phone already has a session, a cache and granted permissions. The reviewer’s phone has none of that.

Before submitting:

delete the app, install the TestFlight build and go through the whole flow from scratch;
deny every permission — camera, notifications, location — and make sure the app explains what happens without them instead of crashing;
run it on an iPad, even if you only built for phones: the reviewer may open it there;
turn the network off, then make it slow — no screen should stay blank forever.

Placeholders and unfinished content

AI loves leaving “Coming soon”, test cards, lorem ipsum and buttons that go nowhere. To a reviewer that means the app isn’t done. An empty section is better removed than shown with a promise.

The same goes for apps that are essentially a website in a shell. If everything inside is what a browser would show anyway, the reviewer will ask why it deserves a place in the store. The answer has to be value the website doesn’t have: offline use, notifications, camera features, a genuinely better phone experience.

Privacy

Many rejections land here, and they’re the most annoying because the code itself works fine.

Privacy policy. The link must open, and the text must describe your app. A generated “covers everything” policy is easy to spot.
The data questionnaire in App Store Connect. List everything the app and its SDKs collect: analytics, crash reports, ads. If the form says “no data collected” and there’s analytics inside, that’s a rejection.
Permission prompts. Strings like NSCameraUsageDescription must explain why: “to photograph your receipt”, not “this app needs the camera”.
Account deletion. If people can sign up, they must be able to delete their account from inside the app, not by emailing support.
Tracking. If you share data for advertising across other companies’ apps and websites, you need the system tracking permission prompt.

Login and sign-up

If the reviewer can’t get past the login screen, it’s a rejection. Put a test account with realistic data in the review notes, and make sure it doesn’t expire or require an SMS code sent to your phone.

Two more frequent notes. First: sign-up is required where it isn’t needed, for example just to browse a catalogue. Second: if you offer third-party login like Google, Apple expects a more privacy-friendly login option next to it — in practice, usually Sign in with Apple.

In-app purchases

The rule in general terms: digital things (subscriptions, credits, premium features, content) are sold through Apple’s in-app purchases. Physical goods and real-world services use a regular payment provider.

Where people trip:

there’s a “Pay by card” button for premium access;
there’s no “Restore purchases” button;
the subscription screen doesn’t show price, period and the fact that it renews automatically;
the reviewer can’t buy in the sandbox because the products aren’t configured.

The rules on linking to outside payment have changed and vary by country — read the current guidelines before submitting, not a summary from last year.

How to respond to an App Store rejection

Read the whole message: it usually names the guideline and what the reviewer saw, sometimes with a screenshot. If the note is fair, fix it, say briefly in your reply what changed, and submit a new build. If the reviewer got it wrong, reply in the same thread in App Store Connect, calmly and to the point, with an explanation and screenshots. There’s also a formal appeal, but use it when the conversation hasn’t worked.

In short

Before submitting, install from scratch, deny permissions and test on an iPad.
Remove placeholders and empty sections; a website wrapper with no value of its own won’t pass.
Your policy, data questionnaire and permission texts must match reality.
Provide a working test account and don’t demand sign-up without a reason.
Digital goods go through in-app purchases, and restoring purchases is mandatory.

SUBXCAT can go through your app with a reviewer’s eyes before you submit, and help with the reply if the rejection has already arrived.