Unresolved App Review issues resubmission checklist
Unresolved issues are easy to ignore because they are not always a hard stop. They still describe risk that can return in the next review.
Turn every unresolved issue into a decision record: fix now, defer with owner, remove feature, or explain in review notes. Apple provides an App Store Connect flow for managing submissions with unresolved issues. AppReviewReady interpretation: a warning that survives approval should still become part of the next release checklist.
Inventory every unresolved item
Record the issue text, guideline, app version, build number, reviewer screenshot, affected platform, and whether the issue blocks release. Do not rely on memory after a stressful review cycle.
If multiple issues point to one workflow, group them by product surface rather than by message order. A paywall problem, metadata claim, and review-note gap may share one root cause.
Choose a release decision
- Fix before release when the issue affects purchase, login, safety, privacy, account deletion, or core functionality.
- Defer only when the issue is informational and has a named owner and next-build deadline.
- Remove or hide the risky feature if evidence is weak and release timing matters.
- Explain in Review Notes when App Review needs a route, account, device, region, or server state.
- Update support macros if users may encounter the same condition after launch.
Prepare the next submission
Before resubmitting, retest the unresolved item from fresh install and from upgrade. If the issue is server-controlled, verify the review environment uses the fixed configuration.
AppReviewReady interpretation: unresolved issues are not permission to ship broken behavior. They are a signal that the next review may have a lower tolerance for the same gap.
Communicate the status clearly
- Write one line per issue: fixed, deferred, removed, or explained.
- Attach the build or metadata field where the change appears.
- If deferred, state when it will be resolved and why the current release is still compliant.
- Avoid claiming an issue is fixed when only a roadmap item exists.
- Keep internal release notes aligned with the App Review response.
Unresolved issue ledger
A ledger prevents the next release from rediscovering the same review risk after code freeze.
After approval, compare unresolved issues with user support tickets and analytics. If users complain about the same workflow, treat the review warning as product evidence, not only compliance paperwork.
Keep unresolved issues visible in sprint planning until they are closed. If a warning is deferred for business reasons, document the risk owner and the trigger that would force a fix before the next submission.
When an issue involves metadata, screenshots, or support copy, retest it outside the binary release process. Non-code edits can revive the same concern without a developer noticing.
For agencies and client apps, share the ledger with the account owner. A client may change pricing, content, or policy copy after approval, and the next review will still judge the submitted app as a whole.
Unresolved issue record: Issue: [summary] Guideline/entity: [reference] Decision: [fix/defer/remove/explain] Owner: [team] Verification route: [steps] Next build impact: [none or required] Support impact: [copy or escalation]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check unresolved review risk
Convert App Review warnings into release decisions before the next submission.
Open the tool