An App Store rejection is not a final verdict. Your next step is to identify exactly what Apple rejected, decide whether the fix changes the binary or only the submission metadata, make the smallest complete correction, and reply with evidence. Do not upload a new build automatically: Apple confirms that some metadata rejections can be resolved and resubmitted with the same build.
This guide gives you the decision process to follow before you change code or send a vague reply.
First, identify what Apple actually rejected
Open App Store Connect → App Review → Resolve and read the complete message. Apple separates an app submission into items: the app version, subscriptions, in-app purchases, in-app events, custom product pages, and other assets can be reviewed together while receiving different outcomes.
Record these four details before doing anything:
- The cited guideline number, such as 2.1, 3.1.1, 4.2, or 5.1.1.
- The exact item marked as rejected.
- The reviewer’s reproduction steps, device, and OS version.
- Whether the message asks for a code change, a metadata change, more information, or working access.
Apple’s submission status reference distinguishes a rejected app bundle from rejected metadata. That distinction is the fastest clue to whether you may keep the current build.
If the message is generic, do not guess. Reply with a concise clarification request that asks which screen, account state, or action produced the issue. Apple allows you to correspond with App Review and attach screenshots or supporting documents before resubmitting.
Decide: reply, edit metadata, or upload a new build
Use this rule: if the fix changes executable behavior or bundled assets, plan a new build; if it only changes editable App Store Connect information, the same build may be enough.
| Situation | Usual next action | New build? |
|---|---|---|
| Reviewer cannot sign in | Verify the demo account, backend, and review notes; reply with tested credentials | Not always |
| Screenshot, description, age rating, or privacy URL is wrong | Correct the relevant metadata and explain the change | Usually no |
| App crashes, a button fails, or purchased content does not unlock | Fix and retest the binary | Usually yes |
| Subscription or in-app purchase was not attached correctly | Correct the product and submission relationship | Depends on the implementation |
| Apple misunderstood a working flow | Reply with exact navigation steps and evidence | No, unless testing reveals a defect |
| You believe the guideline was applied incorrectly | Ask for clarification, then appeal if the disagreement remains | No initial build required |
“Usually” matters here. A metadata-looking problem can reveal a binary defect, and a payment rejection can involve both App Store Connect configuration and StoreKit behavior. Test the complete reviewer path before choosing.
Reproduce the reviewer’s path
Treat the rejection message as a bug report, even when you disagree with its conclusion. Reproduce the same state on the closest available device and OS version.
Check the path from a clean install:
- the app launches without cached credentials or local test data;
- the review account works and does not require a one-time code the reviewer cannot receive;
- the backend is reachable from outside your own network;
- subscriptions and in-app purchases load in the review environment;
- every permission request has a clear purpose string;
- links for support, privacy, account deletion, and restore purchases work;
- the feature described in your screenshots and review notes is actually reachable.
Capture evidence while testing. A short screen recording, one annotated screenshot, and exact tap-by-tap steps are more useful than a long explanation that says the feature “works on our side.”
Make the smallest complete fix
Avoid changing unrelated code during a rejection cycle. Each extra change expands the surface the reviewer must encounter and the surface you must retest.
A complete fix includes three layers:
- The product: code, configuration, content, or account access is corrected.
- The submission: the correct build and every related item are included.
- The explanation: Review Notes and your reply tell the reviewer where to verify the fix.
This is especially important for subscriptions and in-app purchases. Apple’s current submission flow can review these items with an app version, and a rejected item must be edited, updated in the submission, and resubmitted. Fixing StoreKit code alone does not repair a missing product-to-submission relationship.
Write a reply that helps the reviewer verify the fix
A useful reply is short, factual, and testable. It should name the guideline, state what changed, and give the shortest path to verify it.
Use this structure:
Hello App Review,
We reviewed the issue cited under Guideline [number]. We [changed or clarified the specific issue].
To verify:
- [Launch or open a specific screen]
- [Perform the exact action]
- [Describe the expected result]
Review account: [credentials or “unchanged from App Review Information”]
We have attached [screenshot or recording] showing the corrected flow on [device and OS].
Do not claim that Apple is wrong, promise that the app is now compliant, or paste a generic AI-generated defense. Give the reviewer a reproducible path.
Apple’s App Store Connect help says replies can include attachments and notes that metadata issues may be resubmitted with the same build after correction.
When to ask for clarification or appeal
Ask for clarification when the rejection message does not contain enough information to reproduce the issue. Include one or two precise questions, not a broad request to “explain more.”
Consider an appeal when all three conditions are true:
- you understand the cited guideline;
- you have verified the exact behavior and supplied evidence;
- the disagreement is about the guideline’s application, not an unfixed defect.
Apple provides an appeal path when a developer disagrees with a review outcome. An appeal is strongest when it points to the relevant guideline text and explains the product behavior without emotion or speculation. Apple lists clarification, appeals, and review-status support on its App Store support page.
Before you resubmit
Run a final submission check rather than testing only the rejected screen:
- confirm the selected build is the one you tested;
- confirm every rejected item is updated or removed from the submission;
- retest the demo account from a clean device state;
- update Review Notes with exact navigation steps;
- attach only evidence that helps reproduce the corrected behavior;
- read the current App Review Guidelines for the cited section;
- keep a copy of the rejection, your fix, and your response for the next review cycle.
If several items were submitted together, remember that Apple treats the submission as unresolved until every rejected item is corrected, resubmitted, or removed. The unresolved issues documentation explains that accepted items do not make the overall submission approved while another item remains rejected.
Turn the rejection into a repeatable process
The fastest way out of a rejection loop is not a clever reply. It is a disciplined record of the cited rule, the symptom, the verified cause, the product fix, the App Store Connect fix, and the evidence sent back to Apple.
Use the Rejection Decoder to locate the relevant fix path, or start with the pre-submission checklist before your next review. AppRejectKit organizes each common rejection around the same decision: reply, change metadata, submit a new build, retest a flow, or appeal.
This guide is practical product information, not legal advice. Apple changes its rules and submission interfaces; verify the cited guideline before acting.