# App Store Review Guardian > Audit iOS, iPadOS, and visionOS apps before App Store submission by checking the repository, built-app evidence, App Store metadata, privacy disclosures, permission usage, reviewer access, external dependencies, payments, authentication, account deletion, and common App Review risks. Use for Swift, SwiftUI, UIKit, React Native, or Expo projects when Codex needs to prepare for Apple review, investigate likely rejection causes, review metadata or notes, create a reviewer walkthrough, or generate an evidence-linked APP-STORE-REVIEW-REPORT.md and pre-submission checklist directly in Codex. - Skill: `kappaemme-git/app-store-review-guardian` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add kappaemme-git/app-store-review-guardian` - Raw SKILL.md: https://api.skillmd.com/api/skills/kappaemme-git/app-store-review-guardian/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: kappaemme-git (https://skillmd.com/u/kappaemme-git) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kappaemme-git/app-store-review-guardian --- # App Store Review Guardian Try to reject the submission before Apple does. Find credible risks, show the evidence, and create `APP-STORE-REVIEW-REPORT.md` in English in the repository root. Never promise approval or claim to reproduce Apple’s private review process. ## Start safely 1. Resolve the app repository and inspect its local instructions. 2. Ask only for missing material that changes the audit: App Store metadata, review notes, reviewer journey, and whether login, paid services, hardware, location, or region restrictions exist. 3. Never place passwords, API keys, recovery codes, or live reviewer credentials in the report. Record only whether usable credentials were supplied and where the user should enter them in App Store Connect. 4. Treat the audit as read-only unless the user explicitly asks for fixes. ## Refresh official rules App Review rules change. Before each real audit, browse current official Apple sources and record the access date. Use [official-sources.md](references/official-sources.md) as the starting list. Prefer the current App Review Guidelines and App Store Connect Help over memory or third-party rejection lists. Attach an Apple guideline section or official help link to every policy conclusion. If current official guidance cannot be reached, mark policy conclusions `Needs current-rule verification`. ## Collect evidence Run the inventory helper when Node.js is available: ```bash node /scripts/scan_ios_repo.mjs --root --out .codex/app-store-review/repo-scan.json ``` Then inspect the evidence using [audit-playbook.md](references/audit-playbook.md): - project configuration, entitlements, `Info.plist`, Expo config, privacy manifests, dependencies, permissions, network endpoints, authentication, payments, account management, UGC, feature flags, placeholders, and test/demo paths; - supplied title, subtitle, description, screenshots, privacy answers, age rating, support/privacy URLs, release notes, review notes, and reviewer credentials status; - reviewer path from clean install to every important feature, including backend, geography, hardware, subscription, SSO, 2FA, and external-service prerequisites; - mismatches between what metadata promises, what privacy answers declare, what review notes explain, and what the repository appears to do. Static evidence is not proof of runtime behavior or the final uploaded binary. Mark binary-only checks, App Store Connect-only values, live URLs, device behavior, and credentials as `Manual verification` unless actually tested. ## Classify findings Use four result types: - **Blocker**: strong evidence of an incomplete submission, inaccessible core feature, missing required disclosure, invalid configuration, or direct mismatch with current official guidance. - **High risk**: credible rejection or review-delay path requiring action or stronger review notes. - **Review**: plausible concern needing human or on-device confirmation. - **Pass with evidence**: the checked requirement has positive evidence; do not infer passes from absence. Label evidence `Observed`, `Inferred`, `User supplied`, or `Manual verification`. Read [risk-and-evidence.md](references/risk-and-evidence.md) before assigning severity. ## Create the report early Create and continuously update `APP-STORE-REVIEW-REPORT.md`. Follow [report-schema.md](references/report-schema.md). The report must include: - readiness verdict: `READY FOR SUBMISSION`, `READY WITH CONDITIONS`, `NOT READY`, or `INCONCLUSIVE`; - executive summary and audit coverage; - prioritized findings with evidence, official source, remediation, and verification step; - privacy and permissions matrix; - reviewer-access walkthrough and dependency matrix; - metadata-to-product consistency checks; - items that require the archived `.app`, App Store Connect, or a physical device; - copy-ready review-notes draft with secrets omitted; - ordered pre-submission checklist. Render a structured model with: ```bash node /scripts/generate_report.mjs --input .codex/app-store-review/report.json --out APP-STORE-REVIEW-REPORT.md ``` ## Verdict gates - `NOT READY`: any unresolved Blocker or inaccessible core reviewer path. - `READY WITH CONDITIONS`: no Blocker, but unresolved High-risk or manual prerequisites remain. - `READY FOR SUBMISSION`: no unresolved Blocker/High risk, reviewer access is proven, metadata/privacy evidence is consistent, relevant checks pass, and manual submission items are confirmed. - `INCONCLUSIVE`: critical inputs, current official rules, binary evidence, or access path are unavailable. Always end with: this audit reduces avoidable risk but cannot guarantee App Store approval.