App Store rejection appeal: reply, appeal, or fix?

Last updated: July 2026

The three ways to respond to an App Store rejection

Apple gives you three channels, and they are not interchangeable. Picking the wrong one is how a two-day fix turns into a two-week standoff. None of the three requires a new build — that matters, because uploading a binary is what actually restarts your review.

What the 2024 numbers actually say

Rejection is not a signal that something is wrong with you specifically — it's the default state of about a quarter of everything submitted. Apple publishes the figures once a year, and the 2024 report is blunt: reviewers processed 7,771,599 submissions and rejected 1,931,400 of them. Performance — Guideline 2.1, the vaguest number Apple sends — was the single biggest reason, 1,235,471 submissions.

The number that should change how you act is the last one: 295,109 previously-rejected submissions were approved in 2024 after the developer addressed the issue. Rejection is a conversation, not a verdict. And for timing, Apple commits to exactly one figure — on average, 90% of submissions are reviewed in under 24 hours. It publishes no turnaround for appeals, so treat any specific «5–7 day» figure you read elsewhere as a community estimate, not a promise.

Decision tree: fix, reply, or appeal?

Start from what the rejection actually claims, not from how annoyed you are. Read the sentence under the guideline number — that sentence, not the number, tells you which branch you're on.

1. Does the app genuinely do the thing Apple flagged? It crashes, a permission purpose string is empty, ATS is wide open, digital goods sell outside In-App Purchase — then stop reading and fix it. An appeal loses here. Resubmit the corrected build.
2. Is the app fine, but the reviewer couldn't reach a feature or needs a demo account? Reply in the Resolution Center with a numbered path and live credentials. No new build. This clears the large majority of 2.1 «we could not locate the feature» bounces.
3. Did you reply, and the reviewer held a judgement call you believe is wrong — 4.2 minimum functionality, 4.3 spam, a 3.1.1 read of a real-world purchase? Now escalate to the App Review Board, and cite a comparable approved app if you have one.
4. Do you think the guideline itself is ambiguous? Suggest a change — but pair it with a Resolution Center reply, because on its own it won't unblock this build.

The trap is doing two of these at once. Upload a new build while a Board appeal is open and the build supersedes the appeal — you cancel the thing you were waiting on and restart review from zero.

Map your rejection to the guideline — ideally before you submit

This is where reading the actual binary beats any blog. A rejection message names a guideline; our pre-submission auditor reads your .ipa and tells you which guidelines that binary is going to trip before you ever hit submit. Here's the mapping, honest about what the tool reads automatically and what it can only prompt you through.

That's the whole point of running the audit before you submit: the report hands you the guideline number a reviewer would cite, so if a rejection does land, you already know which branch of the tree you're on.

Run the pre-submission audit on your .ipa

Appeal letter templates

Reviewers read a lot of these. The ones that work are short, factual, and free of feelings. Two you can adapt, then a list of lines that quietly sink an otherwise good appeal.

1. «You misread the feature» — a Resolution Center reply (2.1)

Hello, and thank you for the review.

Guideline cited: 2.1
Build: 3.4.0 (219)

We think the feature in question wasn't reached during testing. Here is a numbered path to it:
1. Log in with the demo account below.
2. Tap "Scan" on the home tab.
3. Point the camera at any barcode — the result opens the detail screen your note references.

Demo account
  User: reviewer@ourapp.com
  Pass: Review-2026

The account is live and was verified today. Nothing is gated behind a purchase for this account, and we have not changed the binary. If you can re-test with these steps, we believe the app meets 2.1.

Thank you.

2. «A comparable app is already approved» — an App Review Board appeal (4.3)

We are appealing the rejection of [App name], build 3.4.0 (219), rejected under Guideline 4.3 (Spam).

We disagree that the app is a duplicate, and here is why it is distinct:
- It does [specific function], which no other app we ship does.
- Its codebase and feature set differ from [our other app / any template].

Comparable apps already live on the App Store offer the same core function without being treated as spam — for example [App name, App Store link]. We aren't asking for special treatment, only the same reading.

We have not changed the binary. We'd appreciate a re-examination of the 4.3 decision. If a specific screen looks templated, tell us which one and we'll address it directly.

3. What NOT to say

• Don't threaten the press, social media, or a lawyer. It moves you to the back of the line, not the front.
• Don't argue «you approved it last time». Prior approvals aren't a guarantee, and the reviewer knows it.
• Don't paste the same reply five times. Apple asks for one appeal per submission; repeats slow you down.
• Don't blame the reviewer personally. The person reading your reply didn't write the guideline.
• Don't promise a fix «in the next version» when the reviewer asked a question — answer it in this thread instead of uploading a build you don't need.
• Don't leave the demo account empty or stale. A dead login is the most common reason a 2.1 bounces twice.

Expedited review and the one-appeal rule

Apple lets you request an expedited review for a genuinely time-sensitive case — a critical bug fix or a release tied to an event you're part of. If you ask, include exact steps to reproduce the bug on the current version. Apple typically answers an expedited request within about a day, but spend the credit carefully: overuse gets ignored, and a routine update doesn't qualify.

One hard rule from Apple's own page: submit only one appeal per submission, and respond to any request for information before you appeal. Firing off a Board appeal while an unanswered Resolution Center question is still open is the fastest way to look like you didn't read the rejection.

Apple — App Review (expedited requests and the one-appeal rule)

From the binary to the appeal — closing the loop

Every «how to appeal» article stops at the letter. We don't, because we hold the one thing a blog can't: your actual binary. Before you submit, the auditor parses the .ipa, .apk or .aab and names the exact guideline each finding maps to — ATS to 2.5.1, a missing privacy manifest to 5.1.1, a bad version string to 2.1 — so you fix the guaranteed rejections while you can still edit the build.

And if a rejection lands anyway, the free rejection decoder maps the message you received onto the same guideline, then drafts the Resolution Center reply for you. Pre-submission and post-rejection are the same map read from two ends.

Paste your rejection into the decoder · The most common App Store rejection reasons · The full rejection reasons index, searchable by guideline

FAQ

Sources

• Apple — App Review (channels, expedited, one-appeal rule)
• Apple — App Store Review Guidelines
• Apple — 2024 App Store Transparency Report (PDF)