Compliance

Apple Privacy Manifests (PrivacyInfo.xcprivacy): What They Are, When You Need One, and How to Write Yours

The complete indie-dev guide to Apple's PrivacyInfo.xcprivacy manifest — required reason APIs, which SDKs trigger it, how Xcode validates it, and how it relates to your written privacy policy.

10 min read

Apple Privacy Manifests (PrivacyInfo.xcprivacy): What They Are, When You Need One, and How to Write Yours

You uploaded a new build and received an email: "ITMS-91053: Missing API declaration." Your app uses UserDefaults — every iOS app does — and Apple now wants you to declare why, in a file called PrivacyInfo.xcprivacy. If you ignored the warnings through early 2024, the May 1 deadline caught you; if you are shipping your first iOS app in 2026, the manifest is simply part of the job.

This guide covers what a privacy manifest is, the 2024 timeline, the required reason APIs, how to write the file, common mistakes, and how it relates to — but does not replace — your privacy policy.

TL;DR

  • A privacy manifest is an XML property list named PrivacyInfo.xcprivacy that ships inside your app bundle and declares collected data, tracking domains, and "approved reasons" for using certain Apple APIs.
  • Apple started enforcing missing manifests on May 1, 2024 for new and updated submissions.
  • Required reason APIs include UserDefaults, file timestamps, disk space, system boot time, and active keyboards — categories almost every app touches.
  • The manifest is not a substitute for your privacy policy. Apple's analyzer reads the manifest; users read your policy. Both must tell the same story.
  • AppLander does not generate the .xcprivacy file — that is a Xcode build artifact — but its policy editor keeps the human-readable side in sync with what the manifest declares.

Table of Contents

What a Privacy Manifest Actually Is

A privacy manifest is an XML property list Apple added at WWDC23 to make third-party SDK behavior auditable. The file is named PrivacyInfo.xcprivacy, lives inside your app bundle (and inside every third-party SDK bundle), and contains structured answers to four questions: what data types does this component collect, what tracking domains does it contact, does it track users, and — for a specific list of Apple APIs — what is the approved reason for using each one.

Xcode merges your manifest with every linked SDK's manifest into a combined report Apple's analyzer reads on upload. That report feeds your privacy nutrition label and gets cross-checked against your App Privacy answers.

The manifest moves privacy disclosure from trust-me to show-me. Before, a developer filled out the App Privacy questionnaire by hand and Apple took their word for it. Now the binary declares what it does, and inconsistencies get caught automatically.

The 2024 Enforcement Timeline

Apple's March 13, 2024 developer news post laid out the schedule:

  • March 13, 2024: Email warnings for builds using required-reason APIs without declarations.
  • May 1, 2024: Enforcement began. "Starting May 1, 2024, you'll need to include approved reasons for the listed APIs used by your app's code to upload new or updated apps." Missing declarations now block the upload.
  • Ongoing: New SDKs added to Apple's commonly used SDKs list are subject to the same manifest-and-signature requirement.

In 2026 both deadlines are long past. What you are most likely to encounter is an ITMS-91053 error on upload telling you which API you missed.

Required Reason APIs

Apple's "required reason APIs" are a narrow but inconvenient list. Every app calling one must declare, in its manifest, which of Apple's pre-approved reasons justifies the call. The categories:

  • User defaults — UserDefaults, NSUserDefaults. How every iOS app stores settings, tokens, onboarding flags.
  • File timestamps — creationDate, modificationDate, stat, getattrlist. Reading how old a file is.
  • System boot time — systemUptime, mach_absolute_time. Reading when the device booted.
  • Disk space — NSURLVolumeAvailableCapacityKey and related. Reading free storage.
  • Active keyboards — UITextInputMode.activeInputModes. Listing installed keyboards.

For each category, Apple provides short reason codes — identifiers like CA92.1 or C617.1 — and the manifest must contain at least one for every API the app or its SDKs call.

The trap is that these APIs are not exotic. If you have never written a manifest, your binary almost certainly already calls at least three of these five categories.

The .xcprivacy File Structure

PrivacyInfo.xcprivacy is a standard Apple property list — the same XML format as Info.plist. The root has four top-level keys:

  • NSPrivacyTracking — boolean, true if the app tracks users per Apple's tracking definition.
  • NSPrivacyTrackingDomains — array of tracking domain strings Apple blocks when the user denies tracking.
  • NSPrivacyCollectedDataTypes — array of dictionaries declaring each data type, whether it is linked to identity, whether it is used for tracking, and the purposes.
  • NSPrivacyAccessedAPITypes — array of dictionaries, one per required reason API category, each naming the API type and listing the allowed reason codes.

A minimal manifest for an app using UserDefaults with reason CA92.1 has NSPrivacyTracking false, empty tracking and data arrays, and one NSPrivacyAccessedAPITypes entry naming NSPrivacyAccessedAPICategoryUserDefaults. You add entries as your app or SDKs touch more categories. The file lives at the top level of your app bundle in Xcode.

How Xcode and App Store Connect Validate It

Xcode build time. Xcode merges your manifest with every linked framework's manifest into a combined privacy report, surfaced under Product → Archive → Distribute App → Privacy Report.

App Store Connect upload. Apple's static analyzer scans the binary and compares APIs called against the merged manifest. Any required-reason API called without a declaration returns an ITMS-91053: Missing API declaration error and the build is rejected at upload time.

App Review. Even after upload passes, reviewers flag inconsistencies between the manifest, your App Privacy answers, and in-app behavior. The most common rejection is a manifest saying "no data collected" paired with a policy saying "we collect email addresses for account creation."

Common Mistakes That Cause Rejection

Missing the manifest entirely. Any required-reason API call with no PrivacyInfo.xcprivacy fails upload.

Empty reason arrays. Naming NSPrivacyAccessedAPICategoryUserDefaults with no reasons is as bad as not declaring it. Every category needs at least one code.

Reason code mismatch. Declaring CA92.1 (same-app info) for a UserDefaults call that actually passes data between apps in a group is a direct policy violation.

Forgetting third-party SDKs. Newer commonly-used SDKs must ship their own manifest and signature. Linking an older version that does not fails your upload even when your code is clean.

"No tracking" while linking an ad SDK. NSPrivacyTracking false paired with AdMob or AppLovin is a contradiction Apple's analyzer catches instantly.

App Privacy questionnaire and manifest disagree. Apple cross-checks. "No data collected" in the manifest versus "email, name, phone number" in App Store Connect is a near-guaranteed rejection.

How the Manifest Relates to Your Privacy Policy

The manifest is machine-readable. The privacy policy is human-readable. Different artifacts for different audiences — you need both.

Apple's analyzer reads the manifest. It does not read your prose. It cannot tell you whether the policy actually describes the data you collect, whether the German translation matches the English, or whether the policy still mentions an SDK you removed six months ago. Those problems only a human catches: users, regulators, enterprise customers doing vendor reviews.

Users and regulators never read the manifest. A GDPR data subject access request is not satisfied by pointing to PrivacyInfo.xcprivacy. A CCPA "Do Not Sell" link has to go to a human-readable page. The App Privacy section in App Store Connect is itself a human-readable summary — generated from your answers, not your manifest directly, and the two must match.

The failure mode is drift. You add an analytics SDK, update the manifest, ship, and forget to update the policy prose. Three months later a user reads the old policy, does not see the new SDK, files a complaint. The manifest was right; the policy was wrong; you still defend the gap.

Tools That Help, and Their Limits

Three families of tools cover different parts of the problem. None covers all of it.

Xcode's built-in Privacy Report

The free, first-party option. Xcode merges your manifest with every linked framework's manifest at archive time.

Pros.

  • Built into Xcode, nothing to install or pay for.
  • Shows the exact merged manifest Apple's analyzer reads.
  • Updates every time you archive a new build.

Cons.

  • Reports what is declared; does not author declarations for you.
  • You still have to know which reason code matches your actual API use.

Best for. Every iOS developer shipping to the App Store — step one, not optional.

Third-party static analyzers

Open-source and commercial scanners that read your binary, flag required-reason API calls, and suggest manifest entries. Treat the output as hints.

Pros.

  • Catches API calls deep inside dependencies you did not know about.
  • Useful for auditing older projects before your first manifest.
  • Some generate a starter .xcprivacy draft.

Cons.

  • Quality varies — false positives and missed categories both happen.
  • Still requires you to understand reason codes to pick correctly.

Best for. Developers auditing a large legacy project before their first compliant build.

AppLander (for the human-readable side)

AppLander does not generate the PrivacyInfo.xcprivacy XML file. That is an iOS build artifact produced in Xcode and shipped inside your app bundle. What AppLander does is the human-readable counterpart: the privacy policy editor describes the same data practices the manifest declares.

Pros.

  • Curated library of 100+ mobile SDKs — Firebase, Crashlytics, Sentry, AdMob, AppLovin, RevenueCat, OneSignal, Branch, AppsFlyer, Adjust, OpenAI, Anthropic — each with pre-written disclosure language.
  • SDK drift detection: add a new SDK and AppLander prompts you to update the policy.
  • Version history on every edit, so you can prove what the policy said on any date.

Cons.

  • Does not generate, validate, or read the .xcprivacy file. The manifest is still your responsibility in Xcode.
  • Cannot detect manifest-vs-policy mismatches automatically — you update both when the SDK list changes.

Best for. Developers who want the policy side to stay in sync as the app evolves — and who also need the other compliance assets (terms, support, account deletion, landing page) in one dashboard.

Frequently Asked Questions

Do I need a manifest if I use no third-party SDKs?

Usually yes. If your app calls any required reason API directly — UserDefaults, file timestamps, disk space, boot time, or active keyboards — you need a manifest. Most apps touch at least one.

Does the manifest replace the privacy policy?

No. The manifest is machine-readable metadata inside the bundle. The policy is a human-readable web page both Apple and regulators require separately.

What happens if I ship an update without updating the manifest after adding an SDK?

If the new SDK calls a required reason API without a declaration, the upload fails with an ITMS error before reaching App Review. Upgrade the SDK or switch to a compliant one.

Are SDK authors responsible for their own manifests?

Yes. For SDKs on Apple's commonly-used list, the vendor must ship a .xcprivacy inside the SDK bundle and sign the binary. Xcode merges everyone's manifests at build time.

How do I know which required reason APIs my code calls?

Xcode's Privacy Report at archive time shows what the merged manifest declares versus what the binaries call. ITMS upload errors also tell you precisely which category you missed.

If my manifest says "no data collected" but I collect email addresses, what happens?

Apple rejects the upload, rejects in review, or silently misgenerates the privacy nutrition label — all bad. The manifest must match both your App Privacy answers and binary behavior.

Does updating the manifest require a new build submission?

Yes. The manifest lives inside the bundle, so any change means a new binary. Unlike App Privacy answers (editable any time), the manifest is frozen into each build.

Conclusion

Privacy manifests are not optional. If you are shipping an iOS app in 2026, PrivacyInfo.xcprivacy is part of your submission the same way Info.plist is. The file is small — a minimal manifest is a few dozen lines of plist — and the real work is keeping it honest across every SDK update and every change to the code that calls UserDefaults.

What the manifest cannot do is speak to your users. That is still the privacy policy's job, and the most common failure mode is drift between the two. The manifest gets updated when a new SDK ships; the policy is forgotten.

If you want the human-readable side to stay in sync, try AppLander. The policy editor prompts you whenever you add an SDK from its library. See our privacy policy generators for mobile apps comparison and the App Store rejection reasons 2026 roundup for the rest of the picture.

Sources

Ship your app faster with AppLander

The all-in-one compliance and landing-page platform for mobile app developers.

Start Free