Build an iOS Privacy Manifest Compliance Gate on a Cloud Mac

Once a team moves an iOS project to a cloud Mac, a successful build does not guarantee complete privacy declarations. A dependency update may introduce a new PrivacyInfo.xcprivacy, while an incorrect resource-copy configuration may prevent the main project’s manifest from reaching the final app. A more reliable approach is to treat privacy manifests as part of the build artifact: inspect the source tree first, verify the generated product next, and finally use a version-controlled baseline to block unreviewed changes.

Define the Compliance Gate’s Scope

An actionable gate should cover at least four layers: whether each manifest can be parsed as a plist, whether its top-level fields have the correct types, whether every dependency manifest is included in the review scope, and whether the expected manifests are present in the final app. Do not search only for a single file at the repository root. Source dependencies, prebuilt frameworks, and components checked out by package managers may each carry their own declarations.

Start by creating a manifest inventory in a clean workspace:

find . \
  -path './.git' -prune -o \
  -path './DerivedData' -prune -o \
  -name PrivacyInfo.xcprivacy -print \
  | LC_ALL=C sort > privacy-manifests.current

List the paths explicitly maintained by the project in privacy-manifests.baseline. The pipeline should compare the two files and fail whenever a path is added, removed, or changed. Code owners can then review the change before updating the baseline. This prevents declaration changes introduced by dependency updates from being accepted silently.

A baseline is not proof of compliance. It only shows that the current change received an explicit review; it cannot replace an assessment of what the code actually does.

Validate the Plist and Its Top-Level Structure

plutil -lint can detect malformed XML or binary plists, but it does not verify field types for you. Add a lightweight structural check with Python’s standard library, without installing any extra dependencies:

import pathlib
import plistlib
import sys

allowed = {
    "NSPrivacyTracking": bool,
    "NSPrivacyTrackingDomains": list,
    "NSPrivacyCollectedDataTypes": list,
    "NSPrivacyAccessedAPITypes": list,
}

failed = False
files = sorted(pathlib.Path(".").rglob("PrivacyInfo.xcprivacy"))

if not files:
    print("No privacy manifest found")
    sys.exit(1)

for path in files:
    try:
        with path.open("rb") as stream:
            data = plistlib.load(stream)
        if not isinstance(data, dict):
            raise TypeError("Root must be a dictionary")
        for key, value in data.items():
            expected = allowed.get(key)
            if expected is None:
                raise KeyError(f"Unknown top-level key: {key}")
            if not isinstance(value, expected):
                raise TypeError(f"{key} must be {expected.__name__}")
        print(path)
    except Exception as error:
        failed = True
        print(f"{path}: {error}")

sys.exit(1 if failed else 0)

Save the script as Scripts/validate_privacy_manifests.py and run it before the build. If the project uses internal extension fields, do not simply allow every unknown key. Add each field to the allowlist individually and document its purpose.

Create a Review Matrix for Required Reason APIs

A structurally valid manifest does not necessarily contain valid reasons. Calls involving file timestamps, system uptime, available disk space, preferences, and similar APIs should all be included in code review. Automated scanning can provide useful leads, but macros, abstraction layers, and binary dependencies may cause false negatives or false positives. A single text search should therefore never determine the reason code directly.

Maintain one auditable record for every declaration:

For closed-source binary components, record at least the component version, manifest hash, and the product functionality that requires the component. Do not fill gaps with guesses when a declaration’s origin cannot be explained; confirm it with the dependency owner instead.

Inspect the Final App Again

A source file may not be copied because of an incorrect target membership or resource build phase configuration. The pipeline should perform an unsigned Release build and then inspect the actual product:

rm -rf .build/privacy

xcodebuild \
  -scheme "$SCHEME" \
  -configuration Release \
  -sdk iphoneos \
  -derivedDataPath .build/privacy \
  CODE_SIGNING_ALLOWED=NO \
  build

APP_PATH="$(find .build/privacy/Build/Products -type d -name '*.app' -print -quit)"
test -n "$APP_PATH"
find "$APP_PATH" -name PrivacyInfo.xcprivacy -print | LC_ALL=C sort

The main app, embedded frameworks, and extensions should each appear as expected for the project. Do not hard-code a random DerivedData directory, and do not rely only on the number of source manifests. Multiple source manifests may be merged, replaced, or omitted during the build.

Save an Artifact Inventory

Store the relative path and SHA-256 digest of every manifest in the artifact as a pipeline attachment:

find "$APP_PATH" -name PrivacyInfo.xcprivacy -print0 |
  while IFS= read -r -d '' file; do
    relative="${file#"$APP_PATH"/}"
    digest="$(shasum -a 256 "$file" | awk '{print $1}')"
    printf '%s  %s
' "$digest" "$relative"
  done | LC_ALL=C sort > privacy-artifact.sha256

If a review issue arises, this record answers the question, “What did that build actually contain?” It is more reliable than inspecting the current branch alone.

Integrate Failure Conditions into the Daily Workflow

Split the checks into fast and full tiers. For pull requests, run manifest discovery, plist parsing, field-type validation, and the baseline comparison. On the main branch, also perform the Release build and inspect the app artifact. Fast checks usually identify the relevant path within seconds, while the full checks catch problems in resource build phases and embedded frameworks.

Keep the following checks in place before release:

• The manifest inventory matches the approved baseline.
• Every file passes both plutil -lint and the structural validation script.
• Every new API category is linked to a code location, an owner, and an actual purpose.
• Manifest changes introduced by dependency updates have been reviewed manually.
• The manifests in the final app, extensions, and embedded frameworks match expectations.
• Artifact paths and hashes have been archived with the build.

The purpose of this gate is not to make compliance decisions automatically on the team’s behalf. It is to turn omissions into explicit build failures and make every declaration change traceable to code, dependencies, and review records.

Frequently asked questions