iOS Privacy Manifest: The 2026 Developer Guide to xcprivacy and Required-Reason APIs

Since May 2024, Apple has rejected submissions that use required-reason APIs without a PrivacyInfo.xcprivacy file. As of 2026 it is the second-most-common iOS binary rejection reason after outright crashes, and most teams get tripped not by their own code but by a bundled SDK that doesn’t ship its own manifest.

This post is the 2026 deep dive on the iOS Privacy Manifest: what the PrivacyInfo.xcprivacyfile actually contains, the five required-reason API categories you need to declare, why every bundled framework needs its own manifest, the three specific ITMS rejection codes you’ll see, and the pre-submission workflow that keeps you out of the 5.1.1 rejection queue.

Pair this with the full App Store rejection reasons index for the broader rejection surface, and the 9-minute pre-flight checklist for the tactical pre-submission gate.

What a Privacy Manifest actually is

A Privacy Manifest is a single file — PrivacyInfo.xcprivacy— that ships inside your app binary (and inside every framework or SDK your app depends on) and declares what the code does with user data and system APIs. It is a plist (property list) with a specific schema Apple defined.

Every manifest has four possible sections:

• NSPrivacyTracking— whether the app or SDK tracks users (per Apple’s definition of tracking).
• NSPrivacyTrackingDomains — the domains the app or SDK connects to for tracking purposes.
• NSPrivacyCollectedDataTypes — the categories of user data the app or SDK collects, with usage reasons.
• NSPrivacyAccessedAPITypes — the required-reason API categories the code uses, with the specific reason codes Apple has approved.

The enforcement timeline matters for context. Apple introduced the Privacy Manifest at WWDC 2023, with original enforcement planned for February 2024. That date was pushed to May 1, 2024, when Apple began actively rejecting submissions under the relevant ITMS codes. At WWDC 2024, Apple tightened the requirement further: commonly-used SDKs must now ship signed manifests.

Both your app AND every framework or SDK bundled inside your app need their own manifest. The reviewer doesn’t care which layer of your dependency tree triggered the API call — they care that every layer has declared it.

The 5 required-reason API categories

Apple defined five API categories that require a reason declaration when used. If your app (or any bundled SDK) calls any API in these categories and your manifest doesn’t declare the category with a valid reason code, you’ll be rejected.

Each category has Apple-defined reason codes. For example, the user-defaults category has codes for accessing the app’s own defaults, accessing group defaults shared with other apps from the same team, and a handful of SDK-specific codes. The canonical list is in Apple’s Describing use of required-reason API documentation — it’s updated whenever Apple adds a category or adjusts the valid reasons.

The xcprivacy file structure

PrivacyInfo.xcprivacy is a plist. Here is what a minimal, correct manifest looks like for a small indie app that uses UserDefaults and collects an email address for sign-in:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>NSPrivacyTracking</key>
  <false/>

  <key>NSPrivacyTrackingDomains</key>
  <array/>

  <key>NSPrivacyCollectedDataTypes</key>
  <array>
    <dict>
      <key>NSPrivacyCollectedDataType</key>
      <string>NSPrivacyCollectedDataTypeEmailAddress</string>
      <key>NSPrivacyCollectedDataTypeLinked</key>
      <true/>
      <key>NSPrivacyCollectedDataTypeTracking</key>
      <false/>
      <key>NSPrivacyCollectedDataTypePurposes</key>
      <array>
        <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
      </array>
    </dict>
  </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>

Walking the file top to bottom:

• NSPrivacyTracking = false— the app is not tracking in Apple’s technical sense.
• NSPrivacyTrackingDomains = [] — therefore no tracking domains.
• One collected data type: email. Linked to identity, not used for tracking, purpose is app functionality (sign-in).
• One accessed API type: user defaults. Reason codeCA92.1covers reading the app’s own defaults. Other reason codes exist for group defaults or SDK-specific scenarios — use the one that matches your actual use.

Add the file to Xcode via File → New File → Privacy → App Privacy File(or Framework Privacy File for an SDK). Xcode provides a GUI editor that writes the plist for you, which catches most schema mistakes.

The SDK side (the part most teams miss)

This is where most rejections actually originate. Your own code is usually easy to audit. The hard part is that every framework you bundle — every CocoaPod, every Swift Package, every .xcframework— also needs its own manifest, and you don’t control the vendor’s release cadence.

Apple’s “commonly-used SDKs” list

At WWDC 2024, Apple published a list of approximately 85 SDKs that must ship a signed Privacy Manifest. The list covers the SDKs most commonly used in iOS apps — analytics, crash reporting, ads, identity, and payments:

• Analytics: Firebase/FirebaseAnalytics, Flurry, Mixpanel, Segment, Amplitude-iOS, MobileAppTracker, GoogleAnalyticsTagManager.
• Crash reporting: Crashlytics, Sentry, AppCenterCrashes, Bugsnag, Instabug.
• Ads: Google-Mobile-Ads-SDK, InMobiSDK, IronSource, Pangle, TikTokSDK, UnityAds, Vungle.
• Identity / auth: FBSDKCoreKit, GoogleSignIn, FacebookShare.
• Attribution: Adjust, AppsFlyerLib, Kochava, Branch.
• Payments / subscriptions: Stripe, RevenueCat, PurchaseSDK.
• Other: OneSignal, WeChat, Twitter SDK, PlayFab.

Apple updates the list periodically; the canonical version is in Apple’s Third-party SDK requirements page.

How to check if your SDK ships a manifest

1. Open the framework bundle (right-click the .framework in Finder → Show Package Contents).
2. Look for PrivacyInfo.xcprivacy in the root of the framework.
3. For Swift packages, look in the package’s source directory.
4. If no manifest exists, check the vendor’s latest release — most commonly-used SDKs shipped manifests during 2024.

When an SDK doesn’t have a manifest

Three options, in decreasing order of preference:

1. Update the SDK. Most commonly-used SDKs added manifests during 2024. Check for a newer version first.
2. Drop the SDKif it’s not essential. A SDK without a manifest is also an abandoned SDK in most cases.
3. Vendor a manifest into the framework bundle as a workaround. Create the xcprivacy manually with the categories and reasons the SDK uses, place it in the framework root, re-sign if needed. Not a long-term solution.

App Privacy label vs Privacy Manifest

The two most-confused iOS privacy artefacts. Quick breakdown:

Both are required. They must be consistent. If your App Privacy label says “Data Not Collected” but your Privacy Manifest declares collected data types, Apple rejects. If your manifest declares fewer data types than the label, Apple rejects. Treat them as two views of the same truth and audit them together.

The equivalent concept on Google Play is the Data Safety form — see the App Store vs Google Play listing requirements post for the side-by-side comparison.

The 3 rejection codes you’ll see

Apple surfaces three specific ITMS codes for Privacy Manifest rejections. Each maps to a different underlying problem.

ITMS-91053: Missing API declaration

What Apple says:your app or a bundled SDK uses an API in a required-reason category, but the manifest doesn’t declare that category. The letter names the category (e.g. “theNSPrivacyAccessedAPICategoryUserDefaultscategory is required”) and usually the framework that triggered it.

Fix:add the missing category to your (or the SDK’s) xcprivacy under NSPrivacyAccessedAPITypes with a valid reason code. If the letter names a third-party framework, update the SDK to a version that includes the manifest.

ITMS-91056: Invalid privacy manifest

What Apple says: the manifest is present but malformed — invalid plist syntax, unknown key, invalid reason code, or (since WWDC24) unsigned when the SDK requires signing.

Fix:open the manifest in Xcode’s GUI editor (not a plain text editor) to catch schema errors. Validate reason codes against Apple’s canonical list. For signing issues, update the SDK to a release with a signed manifest.

ITMS-91061: Missing privacy manifest

What Apple says:a bundled framework from the commonly-used SDK list doesn’t ship a manifest at all. Apple names the framework in the letter.

Fix: update the named SDK, drop it, or vendor a manifest into the framework bundle (the last is a workaround, not a fix).

Pre-submission workflow

A five-step audit that catches the common rejections before submitting. Runs in about 15 minutes for a typical indie app.

1. Audit your code. Grep for the common triggers in each required-reason category — especially UserDefaults, NSFileManager timestamp properties, and systemUptime. Confirm each one is declared in your manifest.
2. Write or update your app’s xcprivacy. Use the Xcode GUI editor. Declare the API categories and reason codes. Declare tracking state and any collected data types.
3. Audit every SDK or framework.For each framework in your Frameworks group, confirm a manifest exists in the bundle. Cross-check against Apple’s commonly-used SDK list. Update any SDK without a signed manifest.
4. Diff your App Privacy label against your manifest. Open App Store Connect’s App Privacy section next to your xcprivacy and confirm every declared data type is consistent. Differences trigger the same 5.1.1 rejection.
5. Run a binary scan. Push My App’s Pre-Flight Scanner inspects your .ipa for every required-reason API category triggered by your code or a bundled SDK, and flags any missing or malformed manifest entry before you upload.

This ties into step 5 of the 9-minute pre-flight checklist — the Privacy Manifest is one of the binary-level checks the Scanner automates.

Cross-platform — React Native, Flutter, Unity

Apple’s enforcement happens at the binary level, not at the source level. That means the Privacy Manifest requirement applies regardless of the framework you built the app with.

React Native. Since React Native 0.74, the React Native core ships a base Privacy Manifest. Community plugins (React Native Firebase, React Native Push Notifications, AsyncStorage, etc.) vary — some ship manifests, some lag. Audit each node_modules entry that has an iOS binary.

Flutter.Flutter itself ships a manifest as of Flutter 3.19. Third-party pub.dev plugins vary widely — popular plugins generally have manifests, niche plugins don’t. Check each plugin’s iOS directory.

Unity.Unity ships a manifest as of Unity 2022.3 LTS + iOS Build Support. Third-party Unity packages and store plugins are the most common gap — Unity Ads, Unity Analytics, and Unity IAP ship manifests, but third-party ad-mediation plugins often don’t.

Regardless of framework, the debugging workflow is the same: Apple’s rejection letter names the specific framework that triggered the miss. Update that framework, vendor a manifest if needed, or drop the dependency.

Frequently asked questions