app-rejection-recovery

Turn a rejection into a resubmission within 24–72 hours. The rejection message is the one input that comes from the Chat: the User pastes it verbatim, guideline numbers included. Output is a rejection diagnosis: the guideline, root cause, fix plan and resubmission checklist, ending on the reply draft (or the appeal) the User pastes back into App Review's message thread in App Store Connect.

Gather

1. The pasted rejection — guideline number(s), the device and OS App Review tested on, any screenshot or step they attached. When the paste lacks the guideline number, infer it from the wording using the guideline map and flag the inference.
2. read_context — what the app does, business model (subscription, one-time, free), login model, third-party integrations, the current version and what changed in it when the Foundation doc records releases.
3. connector_asc_localizations when the ASC Connector exists — the latest version and the listing text of every Locale: the metadata fields a metadata rejection points at. Without it, app_store_listing gives the public description and current version, and the diagnosis says the private fields were unverified.
4. The listing the rejection names: when it is 2.3.x (metadata accuracy), the description from app_store_listing; the screenshots from connector_asc_screenshots, looked at with view_image; when it is 3.1.x, the in-app purchases and subscriptions from connector_asc_in_app_purchases.
5. fetch_url on the privacy policy URL when the rejection is 5.1.x — reachable, app-specific, matches the data the app collects. Flagged untrusted.

Diagnose

Classify before writing anything. The guideline-to-bucket map and the per-guideline fix playbook are in references/guideline-map.md; read it for the guideline(s) in the paste. Record:

1. Guideline and bucket — performance, metadata, business, design, spam, privacy, legal.
2. Root cause — one paragraph in plain English, distinguishing what App Review saw from what the app does.
3. Severity — low (metadata or a string), medium (a flow or a screen), high (4.3 spam, 3.1.1 payments, 4.2 minimum functionality: the product itself).
4. Path — fix and resubmit, reply with reproduction information, or appeal. The decision table is in references/reply-and-appeal.md; appeals go to the App Review Board and take five to ten business days, so a fix is the default whenever the guideline was applied correctly.

Draft

Templates for the reply, the appeal and the expedited-review request are in references/reply-and-appeal.md; read it when drafting. The reply acknowledges the guideline, lists the changes made, references the new build number, and carries demo credentials and test steps whenever a reviewer could need them. An expedited request is drafted only for a critical bug, a security fix or a dated event.

Output: rejection diagnosis

• Rejection — guideline(s), bucket, severity, path.
• Root cause — the paragraph.
• Fix plan — code changes, metadata changes (App Store Connect fields, each by name), configuration changes (Info.plist strings, entitlements, privacy labels), estimated effort. Metadata changes are Outputs the User applies.
• Resubmission checklist — tested on the device and OS App Review named, demo account verified, build number incremented, privacy labels match, reply posted, expedited request when justified.
• If rejected again — the next escalation step.
• Prevent — the pre-submission checks from the guideline map that this rejection makes relevant.
• Reply draft — the message for App Review, or the appeal when the path is appeal, ready for the User to paste back.

Done when every guideline in the paste has a bucket, a root cause and a fix, the reply references a build number and demo access, and the diagnosis names the data it lacked (review status, private metadata) when the ASC Connector was absent.

Related Skills

• metadata-optimization — rewriting the description or screenshots text after a 2.3.x rejection.
• screenshot-optimization — screenshots that match the binary after 2.3.10.
• subscription-lifecycle — the subscription disclosures 3.1.2 requires.
• aso — listing health before the next submission.