← Back to Security & Passwords
Security & Passwords by @tristanmanchester

auditing-appstore-readiness

Audit an iOS app repo

0
Source Code

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