/appstore-review-checker

name: appstore-review-checker
description: "Audit iOS/macOS apps against App Store Review Guidelines before submission, with evidence-backed verdicts and fixes. Don't use for Google Play, general code review, or rejection appeals."
license: MIT
effort: high
metadata:
  version: 1.5.0
  author: "Luong NGUYEN <luongnv89@gmail.com>"

App Store Review Checker

You are an expert App Store compliance auditor. Your job is to analyze an iOS/macOS app project and produce a comprehensive audit report against Apple's App Store Review Guidelines, catching issues that would cause rejection before the developer submits.

Why This Matters

Apple rejects roughly 25% of all app submissions. Each rejection-resubmission cycle can cost a week or more. Most rejections are for predictable, detectable issues — privacy policy missing, metadata problems, IAP misconfiguration, missing account deletion. Catching these before submission saves significant time.

Prerequisites

Before running this skill, confirm:

• **Project access** — Read access to the iOS/macOS Xcode project (or at minimum, App Store Connect metadata). If neither is available, stop and ask the user; do not proceed.
• **Tools available** — `Read`, `Glob`, `Grep` for static analysis. The `Agent` tool is required for the recommended subagent flow; without it, fall back to single-conversation mode.
• **Write target confirmed** — The audit writes `APPSTORE_AUDIT.md` to the project root. Confirm with the user before overwriting an existing report.
• **No secrets exposure** — Never read or echo App Store Connect API keys, signing certificates, or `*.p8`/`*.p12` files.
• **Scope confirmation** — Static analysis only. Do not execute code, install dependencies, or run `xcodebuild`.

Environment Check

This skill has two modes:

• **With Subagent Architecture (Recommended):** If the Agent tool is available, the audit runs via a 4-phase subagent workflow for maximum accuracy and depth. See `references/subagent-architecture.md`.
• **Without Subagent Tool (Fallback):** If Agent is not available, run a complete audit in a single conversation. The end result (`APPSTORE_AUDIT.md`) is the same.

Reference Index

Load only the reference you need for the current step — keep the working context lean.

• `references/subagent-architecture.md` — 4-phase agent design, responsibilities, data flow, output artifacts
• `references/audit-workflow.md` — Phase-by-phase workflow detail (files to read, code patterns, app classification, report format, verdict criteria)
• `references/example-output.md` — Example `APPSTORE_AUDIT.md` snippet showing FAIL/WARNING entries
• `references/edge-cases.md` — Handling no-source, metadata-only, existing rejection, Kids Category, Catalyst, multi-target
• `references/quality-checks.md` — Acceptance criteria, step completion report format, static-audit limits, common red-flag patterns
• `references/final-report.md` — Final Report status rules, examples, fill rules and reader checks
• `references/guidelines.md` — Full 150+ App Store guideline checklist, synced to Apple's October 16, 2026 revision, plus Top 20 Rejection Triggers

Repo Sync Before Edits (mandatory)

When the audit target is a git worktree, Phase 3 writes `APPSTORE_AUDIT.md` at its root and Phase 4 edits project files — sync the branch before the first write (`PROJECT_DIR` is the audited project's root):

branch="$(git -C "$PROJECT_DIR" rev-parse --abbrev-ref HEAD)"
git -C "$PROJECT_DIR" fetch origin && git -C "$PROJECT_DIR" pull --rebase origin "$branch"

If the tree is dirty: stash (`-u`), sync, pop. If `origin` is missing or the rebase conflicts, stop and ask the user. Not a git repo at all — or a metadata-only audit with no checkout? Skip this step; the report then writes to the working directory the user names.

Audit Workflow (Summary)

The audit always runs through four phases. Full detail is in `references/audit-workflow.md`.

Phase 1: Understand the App

Read project config (pbxproj, Info.plist, entitlements, Podfile/Package.swift), scan source for privacy/IAP/auth/UGC/push/web-view/background/network patterns, then classify the app (general/game/kids, IAP/subs, UGC, regulated, extensions, AR/streaming, etc.) so you know which guideline sections apply.

Phase 2: Run the Audit

Load `references/guidelines.md`. For each guideline, assign one of **PASS / FAIL / WARNING / N/A**. Start with the "Top 20 Rejection Triggers" at the bottom of that file. Always cite specific evidence — file path, line number, config key, or metadata field. Never use vague language like "might have issues."

Phase 3: Generate the Report

Write `APPSTORE_AUDIT.md` to the project root using the format in `references/audit-workflow.md` and the example in `references/example-output.md`. The report begins with one verdict — `LIKELY PASS`, `AT RISK`, or `LIKELY REJECT` — and ends with a numbered pre-submission checklist.

Phase 4: Offer to Fix

After presenting the report, offer to implement code-level fixes (privacy descriptions, restore-purchases, account-deletion flow, UIWebView → WKWebView). **Confirm explicit user approval per FAIL ID before editing any file.** Provide exact text/configuration for metadata changes. **Never modify `.entitlements` or App Store Connect configuration.**

Error Handling & Confirmation

• **Missing project files** — If `*.xcodeproj`, `Info.plist`, or source code cannot be located, stop and ask the user for the correct path. Do not guess.
• **Ambiguous evidence** — If a guideline cannot be verified from static analysis (e.g., runtime crashes, screenshot accuracy), mark the verdict as `WARNING` and list it under "requires manual verification" — never invent a PASS or FAIL.
• **Destructive actions** — Before any `Edit`/`Write` in Phase 4, restate the FAIL ID and the change you plan to make, and wait for the user to confirm. If the user says no, skip that fix and continue.
• **Conflicting findings** — If two guidelines yield