Privacy manifest and required reason API App Review checklist

Separate privacy manifests from privacy nutrition labels

App Store privacy details are answers you provide in App Store Connect. Privacy manifests are files included by the app or SDKs to describe privacy-related data collection, tracking domains, and required reason API use. One is a storefront declaration; the other is part of the binary and dependency evidence.

A team can pass one check and fail the other. An accurate privacy label does not fix a missing SDK manifest, and a present manifest does not prove App Store Connect answers are accurate. Build the release process so both artifacts are inspected before submission.

Scan app code and SDKs before archive

1. List every Apple framework, third-party SDK, binary framework, package, plugin, and analytics or attribution dependency.
2. Confirm each SDK that needs a privacy manifest includes one in the shipped artifact.
3. Search for required reason APIs used by the app or dependencies and record the selected reasons.
4. Identify tracking domains and compare them with ATT status and privacy-label answers.
5. Archive the exact build and verify the final package contains the expected manifests, not only the source tree.

Reconcile manifests with App Store Connect answers

The manifest inventory should be compared against the app privacy questionnaire, privacy policy, network capture, backend event schema, and SDK vendor documentation. If an SDK declares collection that the label omits, investigate whether the data is actually collected, whether the SDK is configured differently, or whether the label needs to change.

AppReviewReady interpretation: never downgrade a privacy answer merely to match a cleaner marketing story. If the binary or vendor evidence shows collection, update the disclosure or remove the behavior. Treat privacy consistency as a product requirement, not a form-filling task.

Check tracking domains and ATT together

• Tracking domains in manifests should align with whether the app tracks users across apps and websites owned by other companies.
• ATT prompt timing should match the first feature or SDK path that needs tracking permission.
• Denied tracking should prevent tracking behavior, not simply hide the prompt after collection starts.
• Privacy policy, labels, and Review Notes should not describe the same SDK in conflicting ways.

Treat upload warnings as evidence, not noise

Upload and validation warnings about manifests or required reason APIs should be investigated before submission. A warning that seems unrelated to the app's own source may come from an embedded SDK or transitive dependency. Record the owner, fix, and retest result.

If the warning is caused by an SDK version, decide whether to upgrade, remove, replace, or configure it differently. Shipping first and hoping review ignores the mismatch creates avoidable risk for a privacy-sensitive release.

Create a privacy artifact packet

Keep the packet internal unless review asks a specific question. Its main job is to prevent the team from treating privacy label work, SDK updates, and binary validation as three unrelated chores.

Privacy artifact packet:
SDK inventory: [names and versions]
Manifest files verified: [yes/no]
Required reason APIs: [API and reason]
Tracking domains: [domains and ATT relationship]
Privacy label changes: [fields updated]
Policy consistency check: [date and owner]
Open warnings: [none or list]