auditing-appstore-readiness

What this skill does

# App Store Readiness Audit

This skill reviews an app repository and produces a release readiness report for iOS **App Store** / **TestFlight** submission.

It supports:
- Native iOS (Swift/Obj‑C, Xcode project/workspace)
- React Native (bare)
- Expo (managed or prebuild)

## Quick start (recommended)

Run the read‑only audit script from the repo root:

{ "tool": "exec", "command": "node {baseDir}/scripts/audit.mjs --repo . --format md" }

If you want JSON output as well:

{ "tool": "exec", "command": "node {baseDir}/scripts/audit.mjs --repo . --format md --json audit.json" }

If the repo is a monorepo, point at the app directory:

{ "tool": "exec", "command": "node {baseDir}/scripts/audit.mjs --repo apps/mobile --format md" }

## Output contract

Always return:
- Overall verdict: **PASS** / **WARN** / **FAIL**
- Detected project flavour and key identifiers (bundle id, version, build)
- A list of checks with evidence and remediation steps
- A **Publish checklist** the developer can tick off

Use: [references/report-template.md](references/report-template.md)

## Safety rules (don’t break the repo)

Default to **read‑only** commands. Do not run commands that modify the workspace unless:
- the user explicitly asks, **or**
- the fix is trivial and clearly desired (then explain what will change first)

Examples of mutating commands:
- dependency installs (`npm i`, `yarn`, `pnpm i`, `pod install`)
- config generation (`expo prebuild`)
- signing automation (`fastlane match`)
- archiving (`xcodebuild archive`, `eas build`) — creates artefacts and may require signing

If you must run a mutating command, label it clearly as **MUTATING** before running.

## Main workflow

### 1) Identify the repo and project flavour

Prefer scripted detection (`audit.mjs`). If doing manually:

- Expo likely: `package.json` contains `expo` and `app.json` / `app.config.*` exists
- React Native (bare): `package.json` contains `react-native` and `ios/` exists
- Native iOS: `*.xcodeproj` or `*.xcworkspace` exists

If multiple apps exist, pick the one matching the user’s intent; otherwise pick the directory with:
- a single `ios/<AppName>/Info.plist`, and
- exactly one `.xcodeproj` or `.xcworkspace` near the root.

### 2) Run static compliance checks (works everywhere)

Run these checks even without Xcode:

- Repo hygiene: clean git status; obvious secrets not committed
- iOS identifiers: bundle id, version, build number
- App icons: includes an App Store (1024×1024) icon
- Launch screen present
- Privacy & permissions:
  - Privacy manifest present (`PrivacyInfo.xcprivacy`) or explicitly accounted for
  - Permission usage strings present when relevant (camera, location, tracking, etc.)
  - Avoid broad ATS exemptions (`NSAllowsArbitraryLoads`)
- Third‑party SDK hygiene: licences, privacy manifests, tracking disclosures
- Store listing basics: privacy policy URL exists somewhere in repo/docs; support/contact info

The script outputs PASS/WARN/FAIL for these.

### 3) Run build‑accuracy checks (macOS + Xcode, optional but high confidence)

Only if you have **Xcode** available (local macOS gateway or a paired macOS node).

Recommended sequence (creates build artefacts):

1) Show Xcode + SDK versions:
{ "tool": "exec", "command": "xcodebuild -version" }

2) List schemes (project/workspace as detected):
{ "tool": "exec", "command": "xcodebuild -list -json -workspace <path>.xcworkspace" }
or
{ "tool": "exec", "command": "xcodebuild -list -json -project <path>.xcodeproj" }

3) Release build for simulator (fast, avoids signing):
{ "tool": "exec", "command": "xcodebuild -workspace <...> -scheme <...> -configuration Release -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 15' build" }

4) If you need a distribution artefact (**MUTATING / signing**):
- Prefer Fastlane if already configured
- Otherwise `xcodebuild archive` + `xcodebuild -exportArchive`

If build checks aren’t possible, the report must explicitly say so and keep the verdict at **WARN** (unless there are definite FAIL items).

### 4) Produce the final readiness report

- Use [references/report-template.md](references/report-template.md)
- Include a “Go / No‑Go” recommendation:
  - **FAIL** → must fix before submitting
  - **WARN** → submission may work, but risk areas remain
  - **PASS** → ready to submit; remaining items are administrative

## Manual checks the agent cannot fully verify

Always include these as a final checklist section (even if automated checks pass):

- App Store Connect metadata: screenshots, description, keywords, age rating, pricing, categories
- Privacy Nutrition Labels match actual behaviour
- Export compliance (encryption) answers are correct
- Content/IP rights: licences, third‑party assets, trademarks
- Account / regional requirements (e.g. EU trader status if applicable)
- In‑app purchases / subscriptions configured if used

See: [references/manual-checklist.md](references/manual-checklist.md)

## When the user asks “make it compliant”

Switch to fix mode:
1) Identify failing items that can be fixed safely in‑repo (Info.plist strings, `PrivacyInfo.xcprivacy` template, ATS exceptions tightening, etc.)
2) Propose minimal patches and apply with `apply_patch`
3) Re‑run `audit.mjs` and update the report

## Quick search

- Permissions mapping: [references/permissions-map.md](references/permissions-map.md)
- Expo‑specific checks: [references/expo.md](references/expo.md)
- React Native iOS checks: [references/react-native.md](references/react-native.md)
- Native iOS checks: [references/native-ios.md](references/native-ios.md)