ios-app-store-readiness

Files (1)

• SKILL.md

SKILL.md (first lines)

# iOS App Store Readiness

A pre-submission audit, not a guarantee — Apple's actual review process
has human judgment calls this can't predict. This procedure catches the
mechanical, code-visible reasons apps get rejected or delayed.

## 1. Privacy manifest

```bash
find . -name "PrivacyInfo.xcprivacy"
```

If present, check it against actual code:
- **Required-reason API usage** — APIs Apple requires a declared reason
  for (e.g. `UserDefaults`, file timestamp APIs, disk-space APIs,
  system-boot-time APIs) are declared in the manifest if the code
  actually calls them.
- **Collected data types** — types declared match what the code and its
  dependencies actually collect, and whether each is linked to the
  user's identity or used for tracking.
- **Third-party SDK manifests** — SDKs that ship their own privacy
  manifest are current; SDKs that collect data but ship none are a gap
  to flag.

If no `PrivacyInfo.xcprivacy` exists and the app uses any required-reason
API or third-party SDKs that collect data, flag this as a submission
blocker, not a nice-to-have.

## 2. Export compliance

```bash
grep -rn "ITSAppUsesNonExemptEncryption" **/*.plist 2>/dev/null
grep -rln "CommonCrypto\|CryptoKit\|SecKey" --include="*.swift" .
```

- Standard HTTPS/TLS usage is export-exempt; check whether the app also
  implements custom cryptography (`CommonCrypto`, `CryptoKit` beyond
  standard TLS, custom `SecKey` usage) that would need its own export
  compliance documentation, not just the standard exemption.
- `ITSAppUsesNonExemptEncryption` should be set to match reality — set
  to `false` when only using standard exempt encryption avoids an
  unnecessary compliance question at every submission.

## 3. Permission usage descriptions

```bash
grep -o 'NS[A-Za-z]*UsageDescription' **/*.plist 2>/dev/null
grep -rln "AVCaptureDevice\|CLLocationManager\|PHPhotoLibrary\|EventKit\|CNContactStore\|AVAudioSession.*record" --include="*.swift" .
```

Cross-reference: every permission-gated API actually used in code
(camera, location, photos, contacts, calendar, microphone, etc.) needs
a matching `NS*UsageDescription` string in Info.plist, **and** that
string should explain *why* the app needs it, not just restate the
permission name — "This app uses your location" gets rejected far more
often than "Used to show restaurants near you." Flag both a missing
description string and a present-but-generic one.

## 4. App Tracking Transparency

```bash
grep -rln "AppTrackingTransparency\|ATTrackingManager\|AdSupport" --include="*.swift" .
grep "NSUserTrackingUsageDescription" **/*.plist 2>/dev/null
```

If the app uses IDFA or any tracking-adjacent API, it needs
`NSUserTrackingUsageDescription` and must show the ATT prompt
(`ATTrackingManager.requestTrackingAuthorization`) before tracking
actually begins, not after.

## 5. Sign in with Apple parity

```bash
grep -rln "GIDSignIn\|FBSDKLoginKit\|GoogleSignIn" --include="*.swift" .
grep -rln "ASAuthorizationAppleIDProvider\|SignInWithAppleButton" --include="*.swift" .
```

If the app offers a third-party social login (Google, Facebook, etc.)
as a primary sign-in option, Apple requires offering Sign in with Apple
as an equivalent option. This is one of the most common non-obvious
rejection reasons — flag it explicitly if a third-party login is found
without a corresponding Sign in with Apple implementation.

## 6. Unused entitlements & background modes

```bash
find . -name "*.entitlements" -exec cat {} \;
grep -A10 "UIBackgroundModes" **/*.plist 2>/dev/null
```

A requested capability or background mode with no corresponding code
usage is both an unnecessary rejection risk and unnecessary attack
surface (see `ios-security-review` for the security angle on this same
check — don't duplicate that audit here, just flag the App Store risk).

## 7. Common code-level rejection triggers

- Placeholder or "Lorem ipsum" text/images left in shipped UI.
- Obvious crash-on-launch conditions (force-unwraps on data that could
  be missing at first launch, e.g. a nil server response).
- Broken or `http://`-only links to external content (also flagged in
  `ios-security-review`'s transport-security check).
- Any in-app purchase or subscription code that doesn't go through
  StoreKit (App Store rules require IAP for digital goods/services).

## Reporting

Close with the `ios-evidence-reporting` skill's status block (e.g.
`PRIVACY-MANIFEST`, `EXPORT-COMPLIANCE`, `PERMISSIONS`, `ATT`,
`SIGN-IN-PARITY`, `ENTITLEMENTS`) — only categories actually relevant to
what was reviewed, each backed by the file:line evidence or command
output already shown above. This is a code-visible audit only —
metadata, screenshots, and app description content need a human's
review in App Store Connect and are out of scope here.

From apexbymanish/claude-ai-agents-ios, MIT.

More from apexbymanish/claude-ai-agents-ios