Running Apple Privacy Manifest as an Indie Developer — Catching Dependency Drift with Claude Code

The Drift Patterns I See Most Often

Across four long-running apps, almost every Privacy Manifest miss falls into one of four buckets.

1. A new dependency ships without its own PrivacyInfo.xcprivacy. Pods or SPM packages occasionally have a manifest only on a tagged release while the main branch lags, or vice versa.
2. An existing dependency expands its required reasons in a minor version bump. AdMob in particular has tracked Apple's expansions aggressively, which means your own app-level manifest needs to expand in lockstep.
3. Your own code starts using a Required Reasons API. You add a small UserDefaults.standard write for a settings toggle and forget to declare NSPrivacyAccessedAPICategoryUserDefaults.
4. A Swift Package's manifest is not in resources. If you publish a Swift Package as an SDK, the Package.swift resources list must include PrivacyInfo.xcprivacy, or the framework artifact will not bundle it.

These four are easy to miss in code review and tend to surface only at submission time. Conversely, automating these four checks in CI tends to catch most of what would otherwise come back as a rejection.

Drafting Manifests with Claude Code

When you let Claude Code touch Privacy Manifest, give it a reference file at the root of the repo — I use docs/privacy-manifest-context.md — and load it with everything Apple-side that does not live in source. My version has four sections: a mapping of categories to reason codes, an inventory of UserDefaults keys with their purposes, a list of dependencies and the manifest paths they currently ship, and a history of past rejections with the fixes that resolved them.

With that context in place, the prompt I use for initial drafts looks like this.

# Run from the repository root
claude << 'PROMPT'
Read docs/privacy-manifest-context.md and the current PrivacyInfo.xcprivacy,
then produce an update proposal under these constraints.
 
1. Among the Required Reasons API categories my own code touches
   (User Defaults, File timestamp, Disk space, System boot time),
   list the ones that are not yet declared in xcprivacy.
2. For each such category, propose 2-3 candidate reason codes drawn
   strictly from Apple's current reference. Pick one and justify it
   in a single line.
3. Inspect Podfile.lock and Package.resolved. Flag dependencies whose
   bundled xcprivacy implies my app-level manifest needs additions.
 
Return the result as a unified diff against PrivacyInfo.xcprivacy.
PROMPT

The trick here is that the output is requested as a unified diff up front. That makes the patch trivially auditable and trivially applicable with patch -p0 or via Claude Code's Edit tool. Manifests punish typos: one broken character can derail a submission. Free-form prose responses are not worth that risk.

Equally important is treating any "recommended reason code" Claude Code suggests as a candidate rather than a fact, and verifying it against Apple's current reference. Apple updates these categories a few times per year, and a stale reference file will produce confidently wrong answers.

Funnelling Dependency Manifests into a Single Check

You do not need to merge dependency manifests into your own PrivacyInfo.xcprivacy. Xcode will collate them at build time from each Pod or framework bundle. In practice though, you will eventually meet an SDK that simply does not ship a manifest, or that loses it in a packaging step. A small coverage script catches most of this and is straightforward to have Claude Code generate.

#!/usr/bin/env bash
# scripts/check-privacy-manifest-coverage.sh
set -eu
 
PROJECT_DIR="${1:-$PWD}"
TARGET_PODS_DIR="${PROJECT_DIR}/Pods"
 
echo "==> Checking PrivacyInfo.xcprivacy coverage under ${TARGET_PODS_DIR}"
 
MISSING=()
 
if [ -d "${TARGET_PODS_DIR}" ]; then
  while IFS= read -r pod_dir; do
    pod_name=$(basename "${pod_dir}")
    if ! find "${pod_dir}" -name "PrivacyInfo.xcprivacy" -type f \
         -print -quit | grep -q .; then
      MISSING+=("${pod_name}")
    fi
  done < <(find "${TARGET_PODS_DIR}" -mindepth 1 -maxdepth 1 -type d)
fi
 
if [ "${#MISSING[@]}" -eq 0 ]; then
  echo "OK: every Pod ships a PrivacyInfo.xcprivacy"
  exit 0
fi
 
printf "WARN: %d pods without PrivacyInfo.xcprivacy\n" "${#MISSING[@]}"
printf '  - %s\n' "${MISSING[@]}"
exit 1

Wire that script into the front of your Fastlane lane or a Makefile target so CI fails on any WARN. When CI catches a missing manifest, the temporary fix is to have Claude Code synthesize an equivalent xcprivacy and drop it at Pods/<name>/PrivacyInfo.xcprivacy. That is a stopgap, not a real fix — the real fix is the SDK author shipping one — but it has gotten me out of submission jams during peak release windows. On one relaxing-music app I depended on this stopgap for nearly three weeks while waiting for upstream, and it was the difference between staying on the release train and pulling the update entirely.

Wiring Manifest Checks into CI

The point of CI here is to remove the manifest from your daily mental load. My pipeline on GitHub Actions looks like this.

# .github/workflows/privacy-manifest.yml
name: Privacy Manifest
 
on:
  pull_request:
    paths:
      - '**/*.swift'
      - '**/*.m'
      - 'Podfile.lock'
      - 'Package.resolved'
      - '**/PrivacyInfo.xcprivacy'
 
jobs:
  check:
    runs-on: macos-15
    steps:
      - uses: actions/checkout@v4
 
      - name: Install CocoaPods
        run: pod install --repo-update --silent
 
      - name: Check Privacy Manifest coverage
        run: bash scripts/check-privacy-manifest-coverage.sh "${GITHUB_WORKSPACE}"
 
      - name: Detect new Required Reasons API usage
        run: bash scripts/scan-required-reasons.sh "${GITHUB_WORKSPACE}"
 
      - name: Compare manifest against Required Reasons inventory
        run: |
          python3 scripts/diff-privacy-manifest.py \
            --manifest "App/PrivacyInfo.xcprivacy" \
            --inventory "docs/required-reasons-inventory.json"

scripts/scan-required-reasons.sh is a thin grep -rn wrapper that detects calls into Required Reasons API surfaces, and diff-privacy-manifest.py compares the declared categories in PrivacyInfo.xcprivacy against the inventory file. Both are short enough (under 100 lines each) that Claude Code can produce a working first pass when given the repo's CLAUDE.md.

After rolling this out across the four indie apps I run, the average number of review round-trips driven by Privacy Manifest issues dropped from roughly two per month to between zero and one. The months when it lands at zero are worth maybe half a working day each — meaningful when you are also doing the design, the marketing, and the bookkeeping.

Turning a Rejection Log into a Patch

Rejections still happen. The English review messages from Apple often lack specifics, so the manual triage cost is real. The version of this work I have settled on hands the rejection straight to Claude Code and gets back a candidate patch.

# 1. Copy the rejection text from App Store Connect to the clipboard.
# 2. Open the affected repository and start Claude Code.
# 3. Run the prompt below.
 
claude << 'PROMPT'
Read the clipboard contents (the App Store Review rejection message),
plus the current PrivacyInfo.xcprivacy, Podfile.lock, Package.resolved,
and docs/required-reasons-inventory.json.
 
Then do the following.
1. Summarize the rejection reason in one sentence and state what is missing.
2. Produce a unified-diff patch against PrivacyInfo.xcprivacy that fixes it.
3. Propose an addition to required-reasons-inventory.json so that the same
   rejection does not recur silently.
4. Judge whether this can be patched in our app, or whether it requires
   an upstream SDK update.
 
Do not open a PR. Output only.
PROMPT

The "do not open a PR" line is deliberate. With re-submission deadlines pressing, it is tempting to let the agent push, but Apple penalizes manifests that over-declare almost as much as ones that under-declare. The model is reliably good at summarizing the rejection in English and at proposing a diff. It is right about half the time on whether the fix needs an upstream SDK update; you can improve that by feeding it the release notes of the SDK in question.

Operating Principles That Are Worth Keeping

To close, three principles that I have come to trust after twelve years.

First, treat PrivacyInfo.xcprivacy as code. It belongs in CODEOWNERS, deserves a code review, and any dependency-bump PR should carry the matching manifest delta. CI is what guarantees that.

Second, do not let an assistant grow the manifest speculatively. Every category Claude Code proposes should be traceable to a real call site in your inventory. My own rule is that anything without a corresponding entry in required-reasons-inventory.json cannot be merged.

Third, keep a docs/rejection-history.md and make sure Claude Code can read it. Patterns repeat, and once the assistant has seen the same kind of rejection a few times its first-pass suggestion gets noticeably faster and more accurate. On my apps the AdMob-related NSPrivacyAccessedAPITypeReasons rejection that bit me three times has not recurred since I started keeping that file.

Privacy Manifest is invisible to users and adds nothing on the feature axis. For indie developers, though, it is the kind of quiet area where one missed detail can stop a release entirely. With Claude Code holding most of the watch, the energy you save here is energy you keep for what you actually wanted to ship.

Thanks for reading.