Your app got rejected: the reasons, and what to do next

Why was my app rejected?

There are two kinds and their routes differ completely. The first is informational: missing or inconsistent metadata, no demo account, an unexplained permission. Those close within hours, usually without uploading a new build. The second is structural: the app itself breaches a rule — the payment flow, content policy, use of user data. Those require development.

Where teams lose most time is starting work without making that distinction: opening an architecture debate over an informational rejection, or fixing copy and resubmitting against a structural one. The rejection notice names the rule breached by number; start there.

What are the most common App Store rejection reasons?

• No demo account supplied: review cannot get inside an app requiring sign-in. If a verification code is needed, how to obtain it has to be written too.
• A privacy notice missing or at an unreachable address: if the link does not work, the notice counts as absent.
• An unexplained permission: an app requesting location, camera, contacts or notifications has to tell the user why.
• Screenshots not matching the app: an image showing a feature not yet live counts as misleading information.
• Incomplete functionality: review meeting an empty screen — usually for want of test data rather than because of a bug.

How do you reply to the app review team?

The note to the review team should be a guide rather than a defence. The pattern that works: confirm which rule is meant, state in one sentence what you changed, and describe step by step where the change can be seen — which screen, which button, with which account.

The pattern that does not work is equally clear: long texts arguing the rule was misapplied, comparisons pointing out that similar apps do the same, and appeals to urgency. Those do not speed review up and usually slow it down.

Should I appeal a rejection or resubmit?

If you genuinely believe the rule was misapplied there is an appeal route and it should be used — rather than resubmitting repeatedly against the same reason. Where the rejection is justified, however, fixing and resubmitting is always faster; an appeal takes longer than the fix.

The decision rule: if the reason in the notice genuinely exists in your app, fix it; if it does not, appeal. Where you are unsure, fixing is usually cheaper.

What should I check before submitting an app?

• A working demo account and a note covering the verification code flow.
• A live, reachable privacy notice address.
• A purpose string for every permission, matching what the store listing says.
• Screenshots matching the build going live exactly.
• Representative data so empty screens look populated — review looks at the product as a first-time user does.
• For children's apps, consistency between the age rating and the data collection declarations.

How long does review take after a rejection?

A resubmission is usually quicker than the first review because the team sees the earlier assessment. But submitting repeatedly against the same reason puts you at the back of the queue. The practical rule: change something real between submissions and say in the note what you changed — a review that can see no change repeats the same decision quickly.

Can my account be closed?

A single rejection does not put an account at risk. What does is repeated behaviour: submitting the same breach many times, using misleading metadata, hiding a rejected feature and enabling it later. The last is in the heaviest category and leads straight to account termination — hiding a feature from review reads as a breach of trust rather than of a rule.

Can I request an expedited review for something urgent?

Both stores offer expedited review, but it needs a justification: a critical bug affecting users, a security vulnerability or a legal requirement. A campaign date or an investor presentation does not count. Accounts that use the privilege unnecessarily get refused at the next genuine emergency.

Can I remove a rejected feature and add it back later?

No — that behaviour is explicitly prohibited in the guidelines and, when detected, carries a far heavier consequence than the rejection itself. If a feature breaks the rules, the fix is to bring it into line or drop it. If you believe it sits in a grey area, there is a route to consult the store before submitting, and it is much cheaper than enabling it afterwards.

“Most rejections come not from the code but from something the review team could not see.”