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

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 .xcworkspace" } or { "tool": "exec", "command": "xcodebuild -list -json -project .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

• 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

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

• Expo‑specific checks: references/expo.md

• React Native iOS checks: references/react-native.md

• Native iOS checks: references/native-ios.md