An App Store rejection is a negotiation, not a verdict.

The message arrives in formal prose with a guideline number attached, and it reads like a court ruling. First-time developers treat it that way: change everything, resubmit, hope. But on the other side of that message is a person with discretion and a reply box — and knowing how the conversation actually works will save you days per rejection.

Read the citation, ignore the boilerplate

A rejection has two parts: a paragraph of templated language, and a guideline number. The paragraph is often barely customized; the number is the actual message. Before you change a line of code, open the guideline itself and read what it literally says — not what the form letter implies it says. A surprising fraction of panicked rewrites address a rule the reviewer never cited.

Apple's own list of common rejection reasons has been mundane for years: crashes during review, broken links, placeholder content, missing demo credentials. Very few rejections are philosophical disputes. Most are the review equivalent of a failing unit test — specific, local, and fixable the same afternoon.

"Metadata Rejected" is not "Rejected"

App Store Connect uses two statuses that developers routinely conflate, and they call for completely different responses. Rejected means the binary needs to change: you fix the build, upload a new one, resubmit. Metadata Rejected means your app is fine — the problem is in the listing. A screenshot showing content the age rating doesn't allow, a description mentioning the other platform, a support URL that 404s, demo credentials that don't work.

The difference matters because a metadata fix requires no new build. You edit the fields or replace the screenshots, reply in the thread, and the same binary continues through review. Developers who don't know this burn a day cutting a fresh release — version bump, changelog, full upload — to fix a typo in a URL field. Check the status before you touch the code.

The reply box is a real channel

Every rejection opens a message thread in App Store Connect — Apple has long called it the Resolution Center — and the single most underused move in all of app review is replying in it. A human reads those replies. If the reviewer misunderstood what your app does, couldn't find the feature they flagged, or hit a login wall your demo account should have opened, a clear reply can reverse the rejection with no resubmission at all — no new build, no new review queue, just a decision changed by an explanation.

A reply that works looks like a good bug report in reverse. Cite the guideline back at them. Give numbered steps to reach the feature in question. Link a short screen recording that shows the flow working — reviewers spend minutes with an app you've lived in for months, and video closes that gap faster than prose. And make the demo account bulletproof: no SMS verification it can't receive, no regional lockout, no real payment required. A reviewer who can't get past your login screen is required to reject you, and that rejection is entirely self-inflicted.

Tone matters more than it should. The reviewer didn't write the guideline and can't be argued out of it, but they do have discretion in how it applies to your app. Unemotional and specific gets that discretion. Indignant gets the boilerplate.

When you're actually in violation, fold fast

Negotiation has a second half: knowing when you don't have a hand. If the guideline plainly covers what your app does, comply and resubmit — the power asymmetry means you will not win a policy argument in a message thread, and every round trip costs you days. Resubmissions generally move quickly (most reviews clear inside a day), so a fast, complete fix nearly always beats a slow, clever argument.

The one thing that never works is resubmitting the same build unchanged with a note attached, hoping for a different reviewer. Sometimes you get one; usually you get the same rejection later, plus a thread that now reads as evasive.

The appeal exists — spend it carefully

When you genuinely believe a guideline was misapplied — not that the rule is unfair, but that your app doesn't do the thing it was cited for — there's a formal escalation path: an appeal to the App Review Board, filed through a form on Apple's developer site. It's slower than fixing and resubmitting, and it's the wrong tool for routine disagreements. It's the right tool when the interpretation would force a change that guts the product, because an appeal gets fresh eyes with more authority than the original reviewer. Apple's form also accepts suggestions to change a guideline itself; that's feedback, not an appeal, and it won't unblock this release — but it is how several guidelines have softened over the years.

Google Play is a form, not a conversation

Play enforcement runs on a different model. Rejections and removals arrive by email and in the Play Console's policy status page, much of the detection is automated, and the reply box is replaced by an appeal webform. There's less dialogue and less discretion — which changes the strategy. On Play, fixing and resubmitting is almost always faster than appealing, and prevention matters more: keep your declared permissions and Data safety answers exactly consistent with what the binary does, because mismatches are the kind of thing scanners catch and humans don't reconsider. Save the appeal for false positives, and treat it seriously when you do file — repeated violations accumulate against your developer account, not just the app.

Half of "Metadata Rejected" is the listing

Screenshots with prices baked into the pixels, frames showing an Android device on an iOS listing, imagery too mature for the age rating — listing assets are one of the most common ways to get flagged without a single line of code being wrong. ShotCanvas renders store-compliant screenshot sets from your raw screens: exact pixel sizes per slot, per-store rules respected, re-exportable in minutes when a reviewer asks for a change — so the metadata half of the negotiation never starts.