Apple deleted its rejections page, and nothing replaced it

Apple's "Common App Rejections" page no longer exists. Request https://developer.apple.com/app-store/review/rejections/ today and you get HTTP/1.1 301 Moved Permanently with Location: https://developer.apple.com/app-store/review/. Drop the trailing slash and you get the same 301 to the same place.

That destination is not a page either. It is a forwarding stub that serves a <meta http-equiv=refresh> and a JavaScript window.location.replace to /distribute/app-review/. So the URL that used to name your rejection now lands you two hops away on a general App Review overview, and there is no longer any Apple page that maps a rejection to a fix.

What is verifiable, and what is not

The redirect is easy to check yourself:

curl -sI https://developer.apple.com/app-store/review/rejections/

Wayback Machine CDX records for that URL return statuscode 301 on every capture available, from 2020 through to 9 August 2026. So this is long-standing rather than a recent decision, which matters: nobody moved your bookmark last week. The mapping has been missing for years, and the search results that still promise you a "list of common App Store rejection reasons from Apple" are pointing at something that is not there.

What is on the page you land on instead

/distribute/app-review/ carries a section headed "Avoiding common issues". It opens:

"We've highlighted some of the most common issues to help you better prepare before submitting for review. On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more."

Under it, six subheadings: Crashes and bugs, Broken links, Placeholder content, Incomplete information, Privacy policy issues, Unclear data access requests. There is a WWDC session linked from the same section, "Tips for preventing common review issues".

It is genuinely useful material. It is also a different kind of document from the one that went away.

Every subheading links to a guideline rather than describing a rejection letter. The section is organised around what Apple sees most of, and written for someone who has not submitted yet. Nothing in it starts from a sentence a reviewer sent you.

Why the difference matters

The old page did one thing the guidelines structurally cannot do: it ran the lookup backwards.

The App Store Review Guidelines are written as rules for prospective compliance. They tell you what to do before you submit. They are not a diagnostic index, and they were never meant to be, which is why reading 5.1.1 does not tell you which of six possible things a reviewer objected to in your account flow.

"Avoiding common issues" is prevention advice, ordered by Apple's priorities. Useful in week one of a project. Not useful at 11pm on the day a build came back with a paragraph you have read four times.

A rejection is a diagnosis problem. You have a symptom, which is the reviewer's wording, and you need the cause. Without a page that goes from symptom to cause, the search starts from nothing, which is why a rejection now sends developers to search engines, forums and each other. That is not a small gap. It is the single most predictable moment of confusion in shipping an app, and the first party with all the data has stopped publishing the map.

Apple's own numbers make the omission stranger. The same page claims "On average, 90% of submissions are reviewed in less than 24 hours" and that over 40% of unresolved issues sit under one guideline. Apple knows exactly which rejections it sends most often. It just does not publish them indexed by the words it used.

What to use instead, in the order you would really reach for it

1. The Resolution Center message itself. This is your best source and people skim it. The guideline number in the header is the index; the reviewer's own sentences below it are the specifics, and they often name the exact screen, field or step. Read them twice before you read anything else. If the message names a screen, reproduce that screen on a device before forming a theory.

2. The App Store Review Guidelines, used as a lookup. Go to developer.apple.com/app-store/review/guidelines and jump to the number you were cited, rather than reading front to back. Read the paragraph, and read its neighbours: the subsections around your citation often describe the thing the reviewer actually meant.

3. "Avoiding common issues" for 2.1 problems. If your rejection is about crashes, placeholder content, broken links or missing review information, this is the right page, and by Apple's own account that is the largest cluster of unresolved issues.

4. Ask App Review, in Resolution Center. Reply and ask which screen, which step, which device. It is a conversation thread, not a verdict form, and a specific question usually gets a specific answer. This is the step most developers skip in favour of guessing and resubmitting, which costs a review cycle.

5. Apple Developer Forums, App Review tag. Best for one thing: matching the exact wording of a template paragraph to what other people found it meant. The rejection templates are reused, so somebody has almost certainly had your letter.

6. The App Review Board. For escalation, and only when you believe the decision is wrong rather than the app. Have the comparison ready before you go.

That list is worse than one good page. Six sources, no index, and the first two require you to already know how to read a guideline citation. Saying otherwise would be pretending a workaround is a solution.

The practical version

Keep a rejection log. Date, guideline cited, the reviewer's exact wording, what you actually changed, whether it cleared. After three or four rejections you have the diagnostic index Apple stopped publishing, specific to your app and your patterns, which is more useful than a general one anyway.

Then reproduce before you fix. The most expensive rejections are the ones where you changed something plausible, resubmitted, and got the same letter back, having burned a review cycle on a theory.

If you want the reverse lookup that used to exist, the rejection guides here are built that way round: apple-guideline-4-3-a-design-spam and the rest start from the citation and the template wording, then get to the fix. AppSubmit keeps the rejection text, the guideline and the build it applied to in one place so the log above writes itself, but a text file and a habit will do the same job.

metadata-rejected-vs-rejected, because which one you got changes what you fix
in-review-status-meaning
app-store-connect-statuses-explained

Source

Apple, App Review: https://developer.apple.com/distribute/app-review/

Apple, App Store Review Guidelines: https://developer.apple.com/app-store/review/guidelines/