Apple Privacy Manifest: What It Is and How to Create One
Since 2024, App Store submissions need a privacy manifest. This guide explains the PrivacyInfo.xcprivacy file, required reason APIs, tracking domains, how to add one, and the errors to avoid.
An Apple privacy manifest is a PrivacyInfo.xcprivacy file that declares, in machine-readable form, what data your app collects, which privacy-impacting APIs it uses and why, and which domains it contacts for tracking. Since 2024, Apple enforces it at submission: apps and popular SDKs that use flagged APIs must ship a valid manifest or the App Store rejects the upload. This guide explains what goes inside the file, the five required reason API categories, how to declare data and tracking domains, how to add a manifest in Xcode, how third-party SDKs and signatures fit in, how it differs from App Store privacy labels, and the exact errors (like ITMS-91053) that block submission. Prefer to skip all this? Appy Pie AI iPhone App Builder handles it for you.
What This Guide Covers
- What a privacy manifest is
- The 4 manifest keys explained
- Required reason APIs & reasons
- How to add one in Xcode
- Third-party SDKs & signatures
- Common errors (ITMS-91053) to avoid
Build compliant iOS apps with no code. Rated 4.7/5 on G2 from 1,388 reviews.
Get Started FreeTL;DR Quick Summary
An Apple privacy manifest (PrivacyInfo.xcprivacy) is a plist with four keys: NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes and NSPrivacyAccessedAPITypes. It declares what data your code collects, which of the five required reason API categories it uses (with an approved reason code) and which domains it uses for tracking. Since 2024 Apple enforces it: apps or commonly used SDKs that call flagged APIs without a valid manifest (and, for listed SDKs, a signature) are rejected, often after a warning email, with errors like ITMS-91053. Add one via Xcode’s App Privacy template, keep third-party SDKs updated so they ship their own signed manifests, and make sure the manifest agrees with your App Store privacy labels.
Build a Compliant App, No Code →Table of Contents
Jump to any section: what an Apple privacy manifest is, why Apple requires it, what is inside the file, required reason APIs, declaring collected data, tracking and tracking domains, how to add one in Xcode, third-party SDKs and signatures, manifest vs privacy labels, common errors and rejections, no-code and compliance, and the mistakes to avoid, plus an FAQ.
- What Is an Apple Privacy Manifest?
- Why Apple Requires a Privacy Manifest
- What’s Inside a PrivacyInfo.xcprivacy File
- Required Reason APIs Explained
- Declaring Collected Data Types
- Tracking and Tracking Domains
- How to Add a Privacy Manifest in Xcode
- Third-Party SDKs and Manifest Signatures
- Privacy Manifest vs App Privacy Labels
- Common Errors and App Store Rejections
- No-Code Apps and Privacy Compliance
- Privacy Manifest Mistakes to Avoid
- Frequently Asked Questions
What Is an Apple Privacy Manifest?
An Apple privacy manifest is a file named PrivacyInfo.xcprivacy that you include in your iOS, iPadOS, tvOS, watchOS or visionOS app (and that SDKs include in themselves) to declare, in a machine-readable way, what data the code collects, which privacy-impacting APIs it uses and why, and which domains it contacts for tracking. It is a property list (plist) that Apple reads at build and review time.
Apple introduced privacy manifests to make app privacy verifiable rather than self-reported. Instead of trusting a description, Xcode can aggregate every manifest (your app plus all its SDKs) into a single privacy report, and App Store review can check that your declared data use matches reality. Since 2024 it is not optional: apps and popular SDKs that use certain APIs must ship a valid manifest or the App Store rejects the upload.
This guide explains exactly what goes in the file, the required reason APIs, how to add one in Xcode, how third-party SDKs fit in, and the errors that block submission. If you build no-code, this is handled for you, Appy Pie AI iPhone App Builder manages app privacy compliance so you never hand-write a manifest.
Why Apple Requires a Privacy Manifest
Privacy manifests exist to close the gap between what apps say they do with data and what they actually do. Three forces drive the requirement.
Verifiable, aggregated transparency
Your app is not just your code; it is your code plus every SDK you embed. Manifests let Xcode combine all of them into one privacy report, so the privacy picture reflects the whole app, including third-party code you did not write.
Stopping fingerprinting
Some APIs (like device disk space or system boot time) can be abused to fingerprint users even without traditional identifiers. Apple now requires you to declare an approved reason for using these “required reason APIs”, which discourages using them for tracking.
Enforced at submission
Since spring 2024, Apple emails and then rejects uploads that use flagged APIs or SDKs without a valid manifest (and, for common SDKs, a signature). It is a hard gate: no compliant manifest, no App Store.
What’s Inside a PrivacyInfo.xcprivacy File
The manifest is a plist with four top-level keys. Each answers one privacy question about your code.
NSPrivacyTracking
A boolean: does the app or SDK use data for tracking (linking to third-party data for ads or sharing with data brokers) as Apple defines it? If true, tracking must respect App Tracking Transparency.
NSPrivacyTrackingDomains
An array of the internet domains your code connects to that are used for tracking. If a domain is listed here and the user has not granted tracking permission, connections to it are blocked.
NSPrivacyCollectedDataTypes
An array describing each type of data collected (for example, name, email, device ID), whether it is linked to the user, and whether it is used for tracking, plus the purposes.
NSPrivacyAccessedAPITypes
An array declaring each “required reason API” category your code uses and an approved reason code for each. This is the section that trips up most developers.
A minimal manifest for an app that does no tracking but reads its own user defaults looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyTrackingDomains</key>
<array/>
<key>NSPrivacyCollectedDataTypes</key>
<array/>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array><string>CA92.1</string></array>
</dict>
</array>
</dict>
</plist>Each reason code (like CA92.1) maps to an Apple-approved use; you must pick one that genuinely matches how you use the API.
Required Reason APIs Explained
Required reason APIs are a set of common APIs that Apple flags because they can be misused to fingerprint users. If your code (or an SDK) calls one, you must declare its category and an approved reason. There are five categories.
| API category | Example API | An approved reason |
|---|---|---|
| File timestamp | creationDate, modificationDate | Display timestamps to the user (DDA9.1) |
| System boot time | systemUptime | Measure time elapsed for in-app events (35F9.1) |
| Disk space | volumeAvailableCapacity | Check there is space before writing (E174.1) |
| Active keyboard | activeInputModes | A custom keyboard app checking its own keyboards (54BD.1) |
| User defaults | UserDefaults | Access to the app’s own user defaults (CA92.1) |
Pick the reason that honestly matches your use. Declaring a reason you do not qualify for is a policy violation, and “none of the reasons apply” usually means you should stop calling that API for that purpose.
Declaring Collected Data Types
Under NSPrivacyCollectedDataTypes, you describe every category of data your code collects. For each type you specify four things.
- The data type, from Apple’s fixed list (name, email address, device ID, location, purchase history, and so on).
- Linked to the user? Whether the data is tied to the user’s identity.
- Used for tracking? Whether it is used for tracking as Apple defines it.
- Purposes, such as app functionality, analytics, product personalisation or advertising.
These declarations feed directly into the privacy information Apple can show users, so they must match what your app actually does. If your app collects nothing, this array is simply empty.
Tracking and Tracking Domains
Two of the four keys deal specifically with tracking, and they have teeth at runtime, not just at review.
Set NSPrivacyTracking to true only if your app or SDK links user or device data with third-party data for advertising, or shares it with a data broker, Apple’s definition of tracking. If it is true, you must also use App Tracking Transparency to ask permission. List every tracking domain your code contacts under NSPrivacyTrackingDomains. The important consequence: if a domain is declared as a tracking domain and the user has not allowed tracking, the system blocks network connections to it. That means an incorrect or incomplete tracking-domains list can either break your app (over-declaring) or violate policy (under-declaring), so get it right against your actual network calls.
How to Add a Privacy Manifest in Xcode
Adding a manifest to your own app is straightforward. The work is in declaring accurately.
Add the file
In Xcode, choose File then New then File, pick “App Privacy” (the PrivacyInfo.xcprivacy template), and add it to your app target. Xcode gives you a structured editor so you do not have to write the plist XML by hand.
Declare tracking, data and APIs
Set NSPrivacyTracking and list any tracking domains, add each collected data type with its linkage, tracking flag and purposes, and add each required reason API category you use with an approved reason.
Validate and archive
Build and use Xcode’s privacy report (in the Organizer, generate the privacy report from your archive) to review the aggregated manifest for your app plus all SDKs. Fix anything missing, then archive and upload. If a flagged API or SDK lacks a declaration, the upload is rejected with a specific error (covered below).
Third-Party SDKs and Manifest Signatures
Most manifest rejections are not about your code, they are about the SDKs you embed. Apple maintains a list of commonly used SDKs (analytics, ads, networking and more) that must include their own privacy manifest, and for that list, a valid signature.
What this means for you: update your third-party SDKs to versions that ship a privacy manifest and are signed, because an out-of-date SDK without a manifest will block your submission even if your own app is compliant. Xcode’s aggregated privacy report shows which bundled SDKs contribute which declarations, so you can see who is missing one. When you cannot update an SDK, you may have to replace it. Signatures matter because they prove the SDK binary matches its declared manifest and has not been tampered with; Apple verifies them for the SDKs on its list.
Privacy Manifest vs App Privacy Labels
People confuse the privacy manifest with the App Store privacy “nutrition” labels. They are related but different artifacts.
| Aspect | Privacy manifest | App privacy labels |
|---|---|---|
| What it is | A PrivacyInfo.xcprivacy file in your app and each SDK | Answers you enter in App Store Connect |
| Audience | Xcode and App Review (machine-readable) | Users, shown on the App Store listing |
| Covers | Data types, required reason APIs, tracking domains | A human-readable summary of data use |
| Who provides it | You plus every third-party SDK | You, in App Store Connect |
They should agree: the manifest is the verifiable source, and your privacy labels should reflect the same data use. Contradictions between them are a red flag in review.
Common Errors and App Store Rejections
If your upload is rejected for a manifest issue, Apple returns a specific code. The frequent ones:
- ITMS-91053 (Missing API declaration): your app or an SDK uses a required reason API category with no declared reason. Add the category and an approved reason to the manifest.
- ITMS-91054 (Invalid API category): a declared API category is not one Apple recognises, usually a typo in the category string.
- ITMS-91055 / 91056 (Invalid or missing reason): the reason code is wrong for that category, or missing entirely.
- Missing SDK signature/manifest: a commonly used SDK on Apple’s list ships without a manifest or signature; update or replace it.
Apple usually emails a warning first, then enforces with a hard rejection, so treat the warning email as a deadline, not a suggestion.
No-Code Apps and Privacy Compliance
Everything above assumes you are building natively in Xcode and managing your own dependencies. There is a simpler path that removes most of this work.
When you build on a managed no-code platform, the platform builds and signs the app, manages the SDKs, and handles the privacy manifest and required reason API declarations for you, so you are not hand-editing a plist or chasing SDK updates to pass review. You still own your data practices and your App Store privacy labels, but the manifest plumbing is handled.
Appy Pie AI iPhone App Builder builds and publishes your iOS app with app-store compliance, including privacy requirements, managed for you, so you can focus on your product instead of debugging ITMS-91053. New to publishing? See our guide on submitting an iPhone app to the App Store.
Privacy Manifest Mistakes to Avoid
Manifest problems are avoidable once you know the traps. Steer clear of these and your submissions will pass.
The usual failures: forgetting that SDKs need their own manifest and signature (so your compliant app still gets rejected), declaring a required reason API without an approved reason (ITMS-91053), under-declaring tracking domains (a policy violation) or over-declaring them (which blocks legitimate connections), and letting the manifest drift out of sync with your App Store privacy labels. Keep the manifest accurate to your real code, update SDKs, and check both the manifest and the labels together before every submission.
Do this
- Keep the manifest accurate to your real code
- Update SDKs so they ship signed manifests
- Declare an approved reason for every flagged API
- Match the manifest to your App Store privacy labels
- Check Xcode’s aggregated privacy report before upload
Avoid this
- Assuming only your own code needs a manifest
- Declaring a reason you do not qualify for
- Under-declaring tracking domains (policy risk)
- Over-declaring domains (blocks connections)
- Letting the manifest drift from your privacy labels
Skip the Manifest: Build Compliant with No Code
Hand-managing privacy manifests, required reason declarations and SDK signatures is fiddly. Build on a managed no-code platform and the manifest, compliance and publishing are handled, so you never debug an ITMS-91053 rejection.
Get Started Free Read: Submit an iPhone App to the App StoreFrequently Asked Questions
What is an Apple privacy manifest?
An Apple privacy manifest is a file named PrivacyInfo.xcprivacy that you include in your app (and that SDKs include in themselves) to declare, in machine-readable form, what data the code collects, which privacy-impacting ‘required reason’ APIs it uses and why, and which domains it contacts for tracking. Xcode aggregates every manifest into a single privacy report, and App Review checks it. Since 2024, apps and popular SDKs using flagged APIs must ship a valid manifest or the App Store rejects the upload.
Is a privacy manifest required for App Store submission?
Yes, in the common cases. Since spring 2024 Apple enforces privacy manifests: if your app or any commonly used SDK it embeds calls a required reason API, or uses a flagged SDK, without a valid manifest (and, for listed SDKs, a signature), Apple first emails a warning and then rejects the upload. Apps that avoid all flagged APIs and SDKs technically may not need one, but in practice almost every real app does.
What are required reason APIs?
Required reason APIs are common Apple APIs that can be misused to fingerprint users, so Apple requires you to declare an approved reason for using them. There are five categories: file timestamp APIs, system boot time APIs, disk space APIs, active keyboard APIs, and user defaults APIs. For each one your code uses, you add the category and an Apple-approved reason code (like CA92.1 for accessing your app’s own user defaults) to the privacy manifest.
What goes inside a PrivacyInfo.xcprivacy file?
The manifest is a plist with four top-level keys: NSPrivacyTracking (a boolean for whether you track users), NSPrivacyTrackingDomains (the domains used for tracking), NSPrivacyCollectedDataTypes (each data type collected, whether it is linked to the user and used for tracking, and its purposes), and NSPrivacyAccessedAPITypes (each required reason API category you use with an approved reason code). If your app does no tracking and collects nothing, those arrays are simply empty.
What is the difference between a privacy manifest and app privacy labels?
A privacy manifest is a PrivacyInfo.xcprivacy file in your app and each SDK that Xcode and App Review read (machine-readable), covering data types, required reason APIs and tracking domains. App privacy labels are the human-readable answers you enter in App Store Connect that appear on your App Store listing for users. They should agree with each other: the manifest is the verifiable source, and the labels should reflect the same data use. Contradictions are a review red flag.
How do I add a privacy manifest in Xcode?
In Xcode, choose File then New then File, select the App Privacy (PrivacyInfo.xcprivacy) template, and add it to your app target. Use Xcode’s structured editor to set NSPrivacyTracking and tracking domains, add each collected data type, and add each required reason API category with an approved reason. Then generate the privacy report from your archive in the Organizer to review the aggregated manifest (your app plus all SDKs), fix anything missing, and upload.
What is error ITMS-91053?
ITMS-91053 is Apple’s ‘Missing API declaration’ error. It means your app, or an SDK it embeds, uses a required reason API category without declaring an approved reason in the privacy manifest. To fix it, identify the flagged API category from the message, then add that category and a matching Apple-approved reason to your PrivacyInfo.xcprivacy (or update the SDK to a version that ships its own manifest). Apple usually emails a warning before it becomes a hard rejection.
Do third-party SDKs need their own privacy manifest?
Yes. Apple maintains a list of commonly used SDKs that must include their own privacy manifest and a valid signature. An out-of-date SDK without a manifest can block your submission even if your own app is fully compliant. Update your SDKs to versions that ship a signed manifest, use Xcode’s aggregated privacy report to see which bundled SDKs are missing declarations, and replace any SDK that will not update.
Can I avoid writing a privacy manifest?
If you build natively you generally cannot avoid it once your app or its SDKs use flagged APIs, but you do not have to hand-write the XML: Xcode’s App Privacy editor generates it for you. If you build on a managed no-code platform like Appy Pie AI, the platform handles the manifest, required reason declarations and SDK signing as part of building and publishing your app, so you avoid the manual work entirely while still owning your data practices and App Store privacy labels.
Get the Manifest Right, Ship with Confidence
A privacy manifest is not hard once you know the four keys, the five required reason API categories, and that most rejections come from SDKs. Declare accurately, keep SDKs updated and signed, and keep the manifest in sync with your privacy labels. Or skip it entirely: build and publish a compliant iOS app on Appy Pie AI iPhone App Builder, where the privacy manifest is handled for you.
Start Building Free →Build a Compliant iOS App with Appy Pie AI
No code, no dev team, no hand-written manifests. Build and publish your iOS app with app-store compliance, including privacy requirements, handled for you.
Get Started Free4.7/5 on G2 with 1,388 reviews | 10M+ apps & sites built since 2016
Aasif Khan
Head of SEO and Growth Marketing Lead at Appy Pie AI with 17+ years in digital marketing, AI-powered optimization, and scalable growth strategies.
Abhinav Girdhar
Founder and CEO of Appy Pie AI. Builder of one of the world’s largest no-code and AI platforms, with 10M+ apps and websites created.