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
- Resolve the app repository and inspect its local instructions.
- 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.
- 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.
- 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 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:
node <skill-dir>/scripts/scan_ios_repo.mjs --root <repo> --out .codex/app-store-review/repo-scan.json
Then inspect the evidence using 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 before assigning severity.
Create the report early
Create and continuously update APP-STORE-REVIEW-REPORT.md. Follow 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:
node <skill-dir>/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.
1---2name: app-store-review-guardian3description: 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.4---56# App Store Review Guardian78Try 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.910## Start safely11121. Resolve the app repository and inspect its local instructions.132. 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.143. 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.154. Treat the audit as read-only unless the user explicitly asks for fixes.1617## Refresh official rules1819App 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.2021Attach 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`.2223## Collect evidence2425Run the inventory helper when Node.js is available:2627```bash28node <skill-dir>/scripts/scan_ios_repo.mjs --root <repo> --out .codex/app-store-review/repo-scan.json29```3031Then inspect the evidence using [audit-playbook.md](references/audit-playbook.md):3233- 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;34- supplied title, subtitle, description, screenshots, privacy answers, age rating, support/privacy URLs, release notes, review notes, and reviewer credentials status;35- reviewer path from clean install to every important feature, including backend, geography, hardware, subscription, SSO, 2FA, and external-service prerequisites;36- mismatches between what metadata promises, what privacy answers declare, what review notes explain, and what the repository appears to do.3738Static 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.3940## Classify findings4142Use four result types:4344- **Blocker**: strong evidence of an incomplete submission, inaccessible core feature, missing required disclosure, invalid configuration, or direct mismatch with current official guidance.45- **High risk**: credible rejection or review-delay path requiring action or stronger review notes.46- **Review**: plausible concern needing human or on-device confirmation.47- **Pass with evidence**: the checked requirement has positive evidence; do not infer passes from absence.4849Label evidence `Observed`, `Inferred`, `User supplied`, or `Manual verification`. Read [risk-and-evidence.md](references/risk-and-evidence.md) before assigning severity.5051## Create the report early5253Create and continuously update `APP-STORE-REVIEW-REPORT.md`. Follow [report-schema.md](references/report-schema.md). The report must include:5455- readiness verdict: `READY FOR SUBMISSION`, `READY WITH CONDITIONS`, `NOT READY`, or `INCONCLUSIVE`;56- executive summary and audit coverage;57- prioritized findings with evidence, official source, remediation, and verification step;58- privacy and permissions matrix;59- reviewer-access walkthrough and dependency matrix;60- metadata-to-product consistency checks;61- items that require the archived `.app`, App Store Connect, or a physical device;62- copy-ready review-notes draft with secrets omitted;63- ordered pre-submission checklist.6465Render a structured model with:6667```bash68node <skill-dir>/scripts/generate_report.mjs --input .codex/app-store-review/report.json --out APP-STORE-REVIEW-REPORT.md69```7071## Verdict gates7273- `NOT READY`: any unresolved Blocker or inaccessible core reviewer path.74- `READY WITH CONDITIONS`: no Blocker, but unresolved High-risk or manual prerequisites remain.75- `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.76- `INCONCLUSIVE`: critical inputs, current official rules, binary evidence, or access path are unavailable.7778Always end with: this audit reduces avoidable risk but cannot guarantee App Store approval.79
kappaemme-git