A useful App Review reply states the cited issue, the verified correction, whether the build changed, and the shortest path to test it. Keep it factual and attach only relevant evidence.
The short version
- A useful App Review reply states the cited issue, the verified correction, whether the build changed, and the shortest path to test it.
- Write after you reproduce the issue. A polished reply cannot compensate for an unverified fix.
- Name the guideline and exact symptom.
- Do not promise approval; give App Review a testable path.
Classify the message before drafting a reply
Write only after classifying the rejected item, observed symptom, and changed surface. A polished reply cannot compensate for an untested correction or uncertainty about which build Apple will receive.
Create a five-line fact sheet before drafting: guideline and symptom, verified cause, exact change, selected build or metadata state, and reproducible test path. Omit any line you cannot support, then ask a narrow question for the missing fact.
Assemble only verifiable reply facts
Use Apple’s terminology and point to the screen by visible labels. Include credentials in the designated App Review Information fields where appropriate; do not expose secrets or personal data in screenshots or prose.
- Name the guideline and exact symptom.
- State what you verified or changed.
- Say whether a new build is attached.
- Give numbered taps and working credentials.
- End with one precise question only if clarification remains.
Each attachment needs a purpose: show the corrected field, the reachable final state, or a short path that is hard to describe. Evidence should match the current submission, not a development environment.
Choose clarification, correction, or appeal language
Reply with a correction when facts are settled, clarify when Apple’s message lacks a reproducible step, and reserve appeal language for a documented policy disagreement. Never combine an apology, argument, changelog, and escalation into one unfocused message.
| Situation | Next action | New build? |
|---|---|---|
| Access or instruction gap corrected | Reply with credentials and steps | Usually no |
| Metadata-only correction | Name the changed fields | Usually no |
| Runtime defect fixed | Reference the new build and test path | Yes |
| Message too vague to reproduce | Ask for the screen, device, or step | No initial rebuild |
| Policy disagreement after evidence | Clarify, then consider appeal | No initial rebuild |
Let the verified change determine the reply: identify the same build for instructions or external repair, and the new build when executable behaviour changed.
Lead with the resolved issue
Open with the guideline and the reviewer’s observed symptom. Then state the verified cause or correction in one or two sentences. If the cause remains unknown, do not invent one. Describe what you tested and ask for the missing evidence.
Avoid apologies that bury the action and avoid accusations that turn a technical exchange into an argument.
Separate fix from verification
Use a simple order: issue, change, build status, test path, expected result. A reviewer should be able to follow your numbered taps without interpreting product language.
Place credentials in App Review Information as well as the reply when login is required. Test them on a logged-out, clean device first.
Attach evidence with a job
A screenshot can show the corrected field. A short recording can demonstrate a hidden flow. A crash log can identify a fixed failure. Attachments should reduce ambiguity rather than prove that your team worked hard.
Name the device, OS, version, and build when they matter to the reproduction.
Know when to ask instead of assert
If the message lacks a screen, account state, or reproducible action, ask one or two narrow questions. Keep the current build while the classification is unknown.
If you have verified the behavior and disagree about the guideline’s application, explain the evidence before choosing an appeal.
If the reviewer note crosses failure classes, use the App Store rejection map to separate the reply to app review symptom from unrelated issues.
After classifying this reply to app review case, use the post-rejection workflow to sequence the App Store Connect actions.
Use a five-part reply structure
Open with the cited issue and reviewer-visible symptom. Follow with the verified cause, the correction, the selected build or metadata state, and numbered test steps ending in an expected result. This structure lets each sentence do one job.
Example skeleton: “Regarding Guideline [number], you reported [observable result] at [screen]. We verified [cause] and changed [specific surface]. Please review version [version], build [build]. From launch: 1… 2… 3… Expected result: [result].” Remove any bracket you cannot fill truthfully.
Write differently when no change was made
If the issue was missing navigation detail, say where the feature already exists and provide the shortest route. If a service or account was repaired, identify the external change and current verification without claiming permanent availability. If the message is too vague, ask which action, screen, device state, or account result blocked review.
Do not describe an unmodified build as fixed. Distinguish “we changed” from “we verified” so Apple can understand whether to test a new binary or the same submission state.
Keep attachments minimal and safe
A screenshot should show one corrected field or terminal state. A recording should begin before the non-obvious action and stop after the expected result. Redact tokens, personal information, private logs, and unrelated account data.
Send one coherent response channel at a time. If a tested defect was fixed, resubmit and reply. If the current implementation already satisfies the cited rule and clarification did not resolve the disagreement, use the appeal decision guide.
Copy-ready reply checklist
- Exact guideline and observed symptom
- Verified change, not a promise
- Version and build under review
- Numbered route using visible labels
- Expected result and one purposeful attachment
Read the finished reply once as a reviewer who has only the submitted build and the text in front of them. Every noun should identify a visible screen, field, or item; every verb should describe a completed action. Remove internal ticket names, vague assurances, and future-tense promises. If the correction depends on server state, include the UTC verification time. If it depends on a new binary, name the exact version and build instead of saying “latest.”
Verify against Apple before resubmitting
Rules and App Store Connect interfaces can change. Reopen the Apple pages that support this decision before you act: Reply to App Review messages, Manage a submission with unresolved issues. These are the primary policy and workflow sources used for this guide, opened on 4 August 2026.
FAQ about how to reply to App Review
How long should an App Review reply be?
Long enough to state the issue, change, build status, and exact verification path. Most cases do not need an essay.
Can I attach a screen recording?
Apple’s reply workflow supports attachments. Use a short recording when it clarifies a non-obvious path.
Should I say Apple was wrong?
Describe the testing mismatch and ask for a retest. Factual evidence is more useful than assigning blame.
Do I reply and resubmit at the same time?
Use the action that matches the fix. Runtime changes need a build; clarification and many metadata or access fixes do not.
Conclusion
Send a compact chain from observation to verified change to exact test steps. Ask for one missing fact instead of filling uncertainty with argument or assurance.
Sources and references
- Reply to App Review messages (accessed 2026-08-04)
- Manage a submission with unresolved issues (accessed 2026-08-04)