App Store rejection checklist and how to resubmit

This is the unhappy path that sits next to the launch process. Guideline numbers, the wording of templates, and typical review times change; I will refer to issues by topic and point you at the current App Review Guidelines rather than freezing a number or a wait in this page.

Read the rejection as a specific claim

Open the message in App Store Connect, in Resolution Centre, and read all of it, including any attached screenshots and the lines that look like boilerplate. Then write down, in your own words, the claim:

• “The reviewer could not sign in, because…”
• “The privacy policy URL did not load, or did not match the app…”
• “A button or a purchase did not work on the build they installed…”
• “The metadata claims a feature the build does not show…”
• “A permission purpose string is missing or vague…”

If you cannot form that sentence, you are not ready to reply. A rejection often cites a guideline and a short explanation. The explanation and the screenshot are usually more useful than the number, because the number’s wording may cover a family of issues. Follow the link Apple gives you to the current guideline text, and read that section as it stands today.

Don’t start by arguing about tone. Don’t start by submitting a new build that “might help.” Don’t ask a social network what the message “really” means until you have tried the path the reviewer described, on a clean device, with the build they had.

If more than one issue is listed, treat them as a list, not as a vibe. You will need to address each item.

The usual causes on a first submission

First submissions fail for boring reasons more often than for exotic ones. Before you look for a loophole, check:

• The reviewer could not get in. There is no demo account in the review notes, the demo account has expired, sign-in requires a phone number in a country they cannot use, or Sign in with Apple is incomplete.
• The app crashed or hung on launch, on a clean install, or on an iPad if you declared iPad support.
• Placeholder content is still visible: lorem, “coming soon” screens, a broken web view, a test payment environment the reviewer should not have to be in.
• Metadata does not match the binary: screenshots of a feature that is not there, a category that does not fit, a name or subtitle that overclaims.
• Privacy and legal URLs fail to load, redirect to a homepage, or disagree with the app. (HTTP-style failures are worth actually fetching: a 404 is a 404, and the HTTP Status Code Reference is only there to keep those codes straight.)
• A permission is requested without a clear purpose string, or for a purpose the reviewer cannot see in the app.
• Payments go around the system purchase sheet in a way the current guidelines do not allow, or a subscription is described unclearly.
• Hardware or an account the reviewer does not have is required, and you have not explained an alternative path or provided a video.

The privacy manifests and review guide covers a large cluster of these. Many first-time rejections I have seen would have been caught by a clean-install pass and a second pair of eyes on the review notes, which is also why automated tests and a TestFlight install on a device that is not yours are worth doing before you click Submit.

Crashes, broken logins and hidden features

If the reviewer says the app crashed, believe that it did, on their device, in their conditions. Then:

1. Look at the crash reports for the exact build you submitted, in Xcode Organizer or App Store Connect.
2. Install that same build from TestFlight on a second device, delete it, and install again, so you see the first-launch path.
3. Try the path they described, including any deep link or purchase they mention.
4. Fix the crash, or the state that led to it, before you resubmit.

If you cannot reproduce it, say so honestly in the reply, and describe what you have checked. Don’t imply the reviewer invented a crash. A short video of the first-launch path, attached or linked in a way review currently accepts, can help the next pass, but it is not a substitute for a fix if you can find one.

Broken logins are the same family. A demo account should work at the moment of review, from a fresh install, without a one-time code the reviewer cannot receive. If the product is inherently tied to a third-party account (a bank, a university, a workplace), the current guidelines have a process for that; provide whatever review currently asks for, and a clear path in the notes, rather than hoping they will “just understand.”

Hidden or unfinished features should not be in the binary the reviewer is judging. A debug menu, a secret gesture, or a half-built tab that you meant to compile out will be found. If a feature is behind a flag, say so, or remove it.

Permissions, privacy and payments

This cluster has its own depth, and the privacy manifests article is the place for the declarations. In a rejection, the usual shapes are:

• a purpose string that does not describe the actual use, or that is copied from a template (“we need your location to improve the experience”)
• a privacy policy that is missing, unreachable, or contradicted by the privacy labels or by an SDK
• a permission prompt that appears at launch with no context, for a permission the reviewer never then sees used
• tracking or advertising identifiers used in a way you have not declared
• account deletion missing, if you have accounts
• a payment for digital goods or subscriptions that does not use the system in-app purchase, in a situation where the current guidelines require it
• a free trial or subscription whose price, period or cancellation path is not clear

Fix the product and the documents together. A new privacy policy URL with the old SDK behaviour, or a new binary with the old policy, is how you earn a second rejection on the same theme. The Website Brief & Quote Builder is an odd companion here, but it is a useful place to draft a short, factual paragraph of what the app collects and why, before you paste it into the policy and the review notes, so the two do not drift. Keep that paragraph short; the Word Counter will tell you if the notes have turned into an essay.

What to fix, and what to explain

Not every rejection means the app is wrong. Sometimes the reviewer missed a control, landed in a state you did not document, or applied a reading of a guideline you can reasonably clarify. Sometimes the app is wrong, and a long letter will not help.

Fix it, and say that you have, when:

• something crashed, failed to load, or could not be used as described
• a declaration, URL, purpose string or screenshot was inaccurate
• you were clearly on the wrong side of a current guideline

Explain, with evidence, when:

• the feature they could not find is present, and you can say exactly where
• the path requires a setup you have now documented, with a demo account or a video
• you believe the guideline has been applied to a situation it is not aimed at, and you can point to the current text and to how the app actually behaves

Don’t mix a fix and a complaint in a way that hides the fix. Don’t threaten to appeal in the first reply if a short clarification would do. Don’t mention other apps that “do the same thing”; review is not a consistency machine, and what another app got away with is not a defence.

If you disagree and the issue is serious — a legal claim, a business model you believe is allowed, a repeated incorrect reading — you may need to appeal, which is a later section, not a tone of voice in the first box.

The Resolution Centre reply

The reply is for the next reviewer, who may not be the same person, and who will be in a hurry. Write it like a good bug report, in British English, without flattery or anger.

A structure that works:

1. Thank them for the specific pointer (one line, not a paragraph).
2. Restate the issue in a sentence, so it is obvious you have read it.
3. Say what you changed, with the version and build number, or say why no binary change was needed.
4. Tell them how to verify: where to tap, which demo account to use, what they should see.
5. Attach or point to evidence: a screenshot, a short video, a URL that now loads.
6. List any other issue from the rejection, with the same treatment, rather than hoping it was secondary.

Keep the note only as long as it needs to be. If a reviewer asked two questions, use two short headings. Don’t paste a changelog of unrelated bug fixes. Don’t ask them to “approve as soon as possible.” Don’t promise features. Check the current Resolution Centre interface for how attachments and follow-up messages work; the buttons move, the job of the note does not.

If Apple has asked a question rather than issued a formal rejection, answer the question. A week of silence is not a strategy.

Resubmitting, and when to appeal

Resubmit when the build (or the metadata) you are sending actually addresses the claim, and when the notes are ready. Upload the new binary if one is needed, wait until it has processed, attach it to the version, and submit again with the Resolution Centre note already written.

A few practical points:

• Don’t increment your way through five near-identical builds in a day. Each review uses time, and a moving target is harder to assess. Test first, submit once.
• Metadata-only changes sometimes follow a different, lighter path; confirm the current process in App Store Connect rather than assuming a subtitle typo needs a new binary, or that a privacy-policy fix never does.
• Review times vary, and I will not quote a typical number of hours or days. If a delay is unusually long, Apple’s current documentation and the developer support path are the authority, not a remembered average.
• An appeal is for when you have already explained, you believe the decision is wrong under the current guidelines, and you are asking for a formal second look. Follow the appeal process Apple publishes at the time (it has lived in Resolution Centre and in associated support pages). Be factual, attach evidence, and don’t appeal as a first reaction to a crash you have not investigated.
• A phone call or a second-level review may be available in some cases; use official channels, and have the build number and the rejection text in front of you.

If you withdraw a submission, make sure you know whether you are also abandoning the conversation about that rejection. Read the current status labels before you click.

A checklist for the next attempt

• You have restated each issue in your own words, with the current guideline text open next to it.
• You have reproduced, or honestly tried to reproduce, every crash, login failure and missing-feature claim on the submitted build.
• Fixes are in the binary or the metadata you are about to send, and the version or build number in the notes matches that upload.
• Demo accounts, sign-in paths and any hardware workarounds work today, from a clean install.
• Privacy policy, privacy labels, privacy manifest and purpose strings agree with each other and with the app.
• Payments, trials and subscriptions match the current guidelines and the product page.
• Screenshots and descriptions match this build.
• The Resolution Centre reply tells the next reviewer how to verify, in a short, specific note.
• You have not mixed five unrelated changes into the same resubmission without saying so.
• If you are appealing rather than fixing, you have evidence and a guideline-based argument, not only a frustration.

Then wait. Opening the app’s status twelve times an hour will not shorten the queue. Use the time to write a better first-run, or to add a test for the crash you just fixed, so the next submission is quieter.

Key takeaways

• Treat a rejection as a specific claim. Restate it, then fix or explain that claim, not a vague sense of “they didn’t like it.”
• The usual first-submission failures are login, crashes, placeholder content, mismatched metadata, and privacy or payment rules — often visible in a clean-install pass before you submit.
• Reply in the Resolution Centre with the build number, the change, and a verification path a stranger can follow.
• Resubmit once, when the work is actually done. Appeal when you have evidence the decision is wrong under the current guidelines, not as a first reaction.
• Guideline numbers and review times change; use Apple’s current text and processes.

If you want a second pair of eyes on a review note, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.