Two iOS privacy artifacts get confused constantly because both are about data and both have "privacy" in the name: the App Privacy nutrition label and the privacy manifest. They are different things with different jobs. The label is the self-declared disclosure shown to users on your App Store page, filled in through a questionnaire. The privacy manifest is a machine-readable file inside your app and its SDKs that declares required-reason API usage, data types, and tracking domains. They must agree, but they are not the same. Here is what each is, how they relate, and why the distinction matters.
Short answer
The App Privacy nutrition label and the privacy manifest are distinct. Per Apple's App Privacy details, the nutrition label is the privacy disclosure shown on your App Store product page, generated from a questionnaire you complete in App Store Connect about the data your app collects, links, and uses for tracking. The privacy manifest, PrivacyInfo.xcprivacy, is a machine-readable file bundled in your app and your SDKs that declares required-reason API usage, the data types collected, and tracking domains. The label is the user-facing disclosure; the manifest is the in-bundle, per-SDK declaration that feeds into it. They must be consistent with each other and with your app's actual behavior, but they serve different roles.
What you should know
- The label is user-facing: the privacy disclosure shown on the App Store.
- The label comes from a questionnaire: completed in App Store Connect.
- The manifest is a bundled file: PrivacyInfo.xcprivacy in the app and SDKs.
- The manifest is machine-readable and per-SDK: required reasons, data types, tracking domains.
- They must be consistent: with each other and with the app's behavior.
What is the App Privacy nutrition label?
It is the privacy summary users see before downloading. You complete a questionnaire in App Store Connect describing what data your app collects, whether it is linked to the user, and whether it is used to track, and Apple generates the privacy label, the nutrition-style summary, displayed on your App Store product page. It is a disclosure aimed at users, so they can understand your data practices at a glance, and you are responsible for its accuracy, since it must reflect what your app and its SDKs actually do. The label is self-declared through the questionnaire rather than derived automatically, which is why it can be inaccurate if you do not account for everything, especially data collected by third-party SDKs, and why Apple expects it to match the app's real behavior.
What is the privacy manifest?
It is a machine-readable file inside your app and your SDKs that declares specific privacy details. The privacy manifest, named PrivacyInfo.xcprivacy, declares the required-reason APIs your code uses with approved reasons, the data types your app or SDK collects, whether it does tracking, and the tracking domains it contacts. Unlike the label, it lives in the bundle and is per-component: each privacy-impacting SDK provides its own manifest, and your app's manifest plus those of your SDKs together describe the data behavior, which Apple can aggregate into a privacy report. Since a 2025 requirement, privacy-impacting SDKs must include a manifest. So the manifest is the structured, in-bundle source of privacy facts, including the required-reason API declarations that have no equivalent in the user-facing label.
How do the label and manifest relate?
They describe overlapping data practices at different layers and must agree. The table compares them.
| Aspect | Privacy nutrition label | Privacy manifest |
|---|---|---|
| What it is | User-facing privacy disclosure | Machine-readable in-bundle file |
| Where it lives | App Store product page | PrivacyInfo.xcprivacy in the app and SDKs |
| How it is created | Questionnaire in App Store Connect | Declared in the bundle, per component |
| What it covers | Collected data, linking, tracking | Required-reason APIs, data types, tracking, tracking domains |
| Audience | Users | The system and Apple's tooling |
The relationship is that the manifest's collected-data declarations feed into the label, and Apple can use the aggregated manifests to help produce an accurate label. They must be consistent: the data your manifest declares collecting, the label discloses, and both must match what the app actually does. The manifest also carries things the label does not, like required-reason API declarations, which is why you need both, not one instead of the other.
What to watch out for
The first trap is thinking the label and manifest are the same and doing one but not the other; you need the user-facing label and the in-bundle manifest. The second is inconsistency between them, the manifest declaring data the label omits, or either misrepresenting the app, which invites a privacy issue. The third is overlooking that SDKs contribute their own manifests and data behavior, which must be reflected in your label. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the SDKs and data flows in your build, which helps you keep both the manifest and the label aligned with what your app actually does. The declarations you complete in the project and App Store Connect.
What to take away
- The App Privacy nutrition label is the user-facing privacy disclosure generated from an App Store Connect questionnaire; the privacy manifest is a machine-readable in-bundle file.
- The manifest, PrivacyInfo.xcprivacy, declares required-reason APIs, data types, tracking, and tracking domains, per app and per SDK, and feeds into the label.
- They are different artifacts with different roles, and both must be consistent with each other and with your app's actual behavior.
- Use a pre-submission scan such as PTKD.com to see the SDKs and data flows in your build so the label and manifest both match reality.
