# Apple privacy manifests: declare data and required-reason API use > Audit app and SDK manifests, data declarations, required-reason APIs, and tracking domains before upload. > By Dave · 2026-10-11 > Source: https://otf-kit.dev/blog/apple-privacy-manifest-required-reason-apis An iOS app’s privacy manifest is a release artifact: it records data collection and the reasons the app or an included SDK uses certain APIs. That means the review cannot stop at your own source files. An SDK can bring its own data practices and API use into the app you submit. Apple’s privacy-manifest documentation describes what the file records, where an app or SDK includes it, and how to create it in Xcode. Here is a practical pre-upload review that starts with the dependency inventory, separates app-owned declarations from SDK-owned ones, and checks the final bundle. ## What the manifest records Apple describes a privacy manifest as a property list named `PrivacyInfo.xcprivacy`. It records the types of data collected by an app or third-party SDK, as well as required-reason APIs that the app or SDK uses. For each data type collected and each category of required-reason API used, the app or SDK records the relevant reasons in its bundled manifest. The platform scope differs between those two declarations. Apple says data-collection information is required for an app or SDK on all platforms. Required-reason API information is required for apps or SDKs on iOS, iPadOS, tvOS, visionOS, and watchOS. Treat them as separate checks rather than assuming that one filled section covers the other. The file also includes a tracking declaration. `NSPrivacyTracking` is a Boolean that indicates whether the app or SDK uses data for tracking as Apple defines it under App Tracking Transparency. When that value is true, the manifest needs a list of the internet domains the app or SDK connects to that engage in tracking. Apple names that array `NSPrivacyTrackingDomains`. If a person has not granted tracking permission, network requests to those declared domains fail and the app receives an error. These fields make the manifest more than a form to complete at the end. They describe how the software in the submitted bundle uses data and certain APIs. The values should reflect the code and SDK behavior you are actually shipping. ![Dex and Nova compare the app’s own privacy manifest with separate SDK manifest responsibilities](https://cdn.otf-kit.dev/blog/apple-privacy-manifest-required-reason-apis/inbody-app-sdk-manifest-responsibility-20261011a.png) ## Start with the app and every included SDK Make an inventory before editing a file. List the app’s own targets and the third-party SDKs that are packaged with them. For each SDK, identify its distribution form and the manifest it contributes, if any. Apple says apps and SDKs distributed as XCFrameworks, Swift packages, or Xcode projects can contain a privacy manifest. That inventory is a practical review step, not an Apple-prescribed format. Its purpose is to stop a common coverage gap: recording the app’s own collection while overlooking an SDK that collects data, accesses a required-reason API, enables the app to collect data, or contacts tracking domains. Apple gives specific guidance for SDK manifests. An SDK listed in “SDKs that require a privacy manifest and signature” needs to include one. If an SDK is not on that list, Apple says it still needs a manifest when it uses a required-reason API, collects data about the person using apps that include it, enables the app to collect data about people using the app, or contacts tracking domains. Do not treat the app’s manifest as a substitute for an SDK’s own declaration. Apple says an SDK cannot rely on the manifests of apps that link it, or of other linked SDKs, to report that SDK’s use of required-reason APIs. The component using the API has a reporting responsibility in its own manifest. ## Create and bundle the file in Xcode In Xcode, Apple’s documented route is File → New File, then choose “App Privacy File” in the Resource section. Select the app or SDK target that owns the manifest and create the file. Xcode names it `PrivacyInfo.xcprivacy`; Apple identifies that as the required name for bundled privacy manifests. Confirm that the file belongs to the intended target’s resources. Apple notes that Xcode needs the manifest in the target’s resources to use it when generating a privacy report. A file sitting in the repository but excluded from the target does not meet that bundling step. A third-party SDK distributed as a static library needs particular attention. Apple’s documentation says to use Xcode’s support for static frameworks, available in Xcode 15 or later, to bundle resources such as the privacy manifest. It describes creating a framework target that builds the product, setting its Mach-O type to “Static Library,” and adding the manifest to the target’s bundle resources. Follow the current Apple instructions for the SDK’s packaging model rather than copying this setup into a different distribution format. ## Review the declarations against actual behavior At the top level of the property list, Apple describes four keys relevant to these declarations: - `NSPrivacyTracking`: a Boolean indicating whether the app or SDK uses data for tracking under the App Tracking Transparency definition. - `NSPrivacyTrackingDomains`: an array of internet domains that the app or SDK connects to for tracking. Apple says to provide this list when tracking is true. - `NSPrivacyCollectedDataTypes`: an array describing the data types collected by the app or SDK. - `NSPrivacyAccessedAPITypes`: an array describing API types the app or SDK accesses that Apple has designated as requiring reasons. For each required-reason API category used, Apple says to add a dictionary to `NSPrivacyAccessedAPITypes` that reports the reasons for that use. When the app’s own code uses one, report it in the app’s manifest. When a third-party SDK uses one, report it in that SDK’s manifest. The API category and reason values must come from Apple’s allowed lists; use the documentation for the dictionary keys to check the current categories, APIs, and accepted reasons. Choose the reason that describes the real use in the shipped software. Apple says declared reasons must accurately reflect how the app or SDK uses each API and data derived from it, and must be consistent with the app’s functionality as presented to users. The allowed reason is not a broad permission to use the API or resulting data for another purpose. For collected data, compare the manifest with what the app and each SDK collect. For tracking, verify whether the tracking Boolean is accurate and whether each tracking domain belongs in the declared list. These are review questions derived from the fields Apple documents; they are not a replacement for inspecting the implementation or asking an SDK provider about behavior that is not clear. ![Byte audits declared data and API-use categories alongside generic destination domains](https://cdn.otf-kit.dev/blog/apple-privacy-manifest-required-reason-apis/inbody-data-api-domain-audit-20261011a.png) ## Run a pre-upload review A repeatable release review can look like this: 1. Inventory app targets and included third-party SDKs, including their distribution forms. 2. Check whether each SDK is on Apple’s list of SDKs that require a manifest and signature. 3. Identify data collection, required-reason API use, enabled app collection, and tracking-domain behavior for each component. 4. Confirm that each component that needs a manifest has its own `PrivacyInfo.xcprivacy` in the bundle resources. 5. Compare data types, API categories, approved reasons, the tracking Boolean, and tracking domains with the behavior you are shipping. 6. Generate and inspect the privacy report from the built target, confirming Xcode includes the bundled file. 7. Re-run the review when you add or update an SDK, change data flows, or alter API use. The inventory and repeat-review cadence above are operating practices to make Apple’s documented declarations easier to verify. Apple’s page explains the manifest structure and inclusion rules; it does not prescribe a particular team spreadsheet or release checklist. If a third-party SDK’s behavior is unclear, do not guess at its data types, API categories, or reasons. Check its included manifest and vendor documentation, then ask the vendor for details that the materials do not establish. Keep the record tied to the exact dependency version you build so a later update does not silently change what you reviewed. ## Keep the scope precise A privacy manifest is one part of app privacy work. This guide covers the declarations in Apple’s manifest documentation; it does not determine whether a particular app complies with every privacy, consent, or store-review rule. It also does not identify which APIs a specific SDK uses. Check Apple’s current list and the SDK’s own materials before submitting. For a related view of the information people see in store privacy disclosures, read [how to prepare privacy labels for an AI-built app](/blog/app-privacy-labels-ai-built-app). Keep that disclosure review and the manifest review connected to the same current inventory of the app and its SDKs. ## Sources - Apple Developer Documentation, [Privacy manifest files](https://developer.apple.com/documentation/bundleresources/privacy-manifest-files) and its linked article, [Describing use of required reason API](https://developer.apple.com/documentation/bundleresources/describing-use-of-required-reason-api); checked October 11, 2026.