← All articles

Missing Privacy Manifest iOS Rejection — How to Fix ITMS-91053

·12 min read

You uploaded your build to App Store Connect, waited for processing, and got hit with this:

ITMS-91053: Missing API declaration — Your app's code in the "(YourApp)" file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is currently required for this issue, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app's privacy manifest to provide approved reasons for these APIs.

Since May 2024, Apple enforces this as a hard rejection. If your binary references any of the Required Reasons APIs without a corresponding privacy manifest entry, your build will be rejected during processing — before it even reaches review. As of early 2026, Apple has tightened enforcement further, flagging transitive references from third-party SDKs and frameworks that previously slipped through.

This guide walks you through exactly what went wrong, how to fix it, and how to prevent it from happening again.

What Is PrivacyInfo.xcprivacy

PrivacyInfo.xcprivacy is Apple's privacy manifest file. It is an XML property list (plist) that ships inside your app bundle and declares what sensitive APIs your code accesses and why. Apple introduced it as part of the privacy manifest initiative announced at WWDC 2023 and enforced starting in Spring 2024.

The file lives at the root level of your Xcode project target. For frameworks and Swift packages, each one can include its own PrivacyInfo.xcprivacy inside its resource bundle. When you archive your app, Xcode aggregates all privacy manifests from your app and its dependencies into a single privacy report.

The Four Key Sections

A privacy manifest has four top-level keys:

  • NSPrivacyTracking — Boolean. Set to true if your app or SDK uses data for tracking as defined under App Tracking Transparency. Most apps set this to false.

  • NSPrivacyTrackingDomains — Array of strings. Domains your app connects to for tracking purposes. If NSPrivacyTracking is false, this can be an empty array.

  • NSPrivacyCollectedDataTypes — Array of dictionaries. Each entry describes a category of data your app collects (e.g., email address, location, device ID), why it is collected, and whether it is linked to the user's identity.

  • NSPrivacyAccessedAPITypes — Array of dictionaries. This is the section that causes ITMS-91053. Each entry declares an API category your code accesses and the approved reason codes for that access.

The rejection you are getting is specifically about missing or incomplete NSPrivacyAccessedAPITypes entries.

Required Reasons APIs — Full List with Reason Codes

Apple defines five categories of APIs that require declared reasons. If your binary contains any symbol references to these APIs — even if the code path is never executed — you must declare a reason.

File Timestamp APIs

Category: NSPrivacyAccessedAPICategoryFileTimestamp

APIs in this group include NSFileCreationDate, NSFileModificationDate, NSURLContentModificationDateKey, NSURLCreationDateKey, getattrlist(), stat(), fstat(), and related functions.

Common reason codes:

  • C617.1 — Access file timestamps inside the app container, app group container, or CloudKit container.
  • 0A2A.1 — Access file timestamps for files the user explicitly granted access to via a document picker or similar UI.
  • 3B52.1 — Access file timestamps to determine whether a file has changed since last read, for purposes of data caching or content validation.

Most apps use C617.1 (accessing timestamps of their own files) and/or 3B52.1 (cache invalidation).

System Boot Time / Uptime APIs

Category: NSPrivacyAccessedAPICategorySystemBootTime

APIs include ProcessInfo.systemUptime, mach_absolute_time(), and mach_continuous_time().

Common reason codes:

  • 35F9.1 — Measure elapsed time within the app (e.g., timing operations, animations, throttling).
  • 8FFB.1 — Calculate absolute timestamps for events occurring within the app for logging or diagnostics.

If you use any timer-based logic, performance monitoring, or duration tracking, you likely need 35F9.1.

Disk Space APIs

Category: NSPrivacyAccessedAPICategoryDiskSpace

APIs include URLResourceKey.volumeAvailableCapacityKey, URLResourceKey.volumeAvailableCapacityForImportantUsageKey, URLResourceKey.volumeAvailableCapacityForOpportunisticUsageKey, URLResourceKey.volumeTotalCapacityKey, statfs(), and statvfs().

Common reason codes:

  • 85F4.1 — Display disk space information to the user (e.g., showing available storage).
  • E174.1 — Check whether there is sufficient space before writing files to disk.
  • 7D9E.1 — Used by the operating system to manage storage (system apps only, rarely applicable).

Most apps need E174.1 if they download or cache content.

User Defaults APIs

Category: NSPrivacyAccessedAPICategoryUserDefaults

This covers UserDefaults — one of the most commonly used iOS APIs.

Common reason codes:

  • 1C8F.1 — Access UserDefaults to read and write data accessible only to the app itself (the app's own container). This is the reason almost every app needs.
  • C56D.1 — Access UserDefaults from an app extension to share data with the containing app or other extensions in the same app group.
  • AC6B.1 — Access UserDefaults to read the com.apple.configuration.managed key set by MDM (Mobile Device Management).

If your app uses UserDefaults at all (and virtually every iOS app does), you need at least 1C8F.1.

Active Keyboard APIs

Category: NSPrivacyAccessedAPICategoryActiveKeyboards

APIs include UITextInputMode.activeInputModes.

Common reason codes:

  • 3EC4.1 — Determine the active keyboard to set the correct language for text processing (e.g., spell check, autocomplete).
  • 54BD.1 — Determine the active keyboard to present the correct localized UI to the user.

This category is less common and primarily affects apps with localization or text input features.

Example Privacy Manifest XML

Here is what a typical PrivacyInfo.xcprivacy file looks like for an app that uses UserDefaults, file timestamps, and system uptime:

<?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/>
  <key>NSPrivacyAccessedAPITypes</key>
  <array>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>1C8F.1</string>
      </array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>C617.1</string>
        <string>3B52.1</string>
      </array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>35F9.1</string>
      </array>
    </dict>
  </array>
</dict>
</plist>

You can create this file manually or through Xcode's property list editor. If you use the Xcode editor, add a new file of type "App Privacy" — Xcode will generate the correct structure for you.

Third-Party SDKs Missing Privacy Manifests

Your own code is only half the story. The most common cause of ITMS-91053 is a third-party SDK that references Required Reasons APIs but does not ship its own privacy manifest.

Which SDKs Are Affected

Apple publishes a list of commonly used third-party SDKs that must include their own privacy manifests. This includes Firebase, Google Analytics, Facebook SDK, Crashlytics, Alamofire, and many others. As of late 2025 and into 2026, most actively maintained SDKs have added their privacy manifests. The problem arises when:

  • You are pinned to an older version of a dependency that predates privacy manifest support.
  • You use a less popular or unmaintained SDK that never added a manifest.
  • Your dependency manager cached an older version that does not include the manifest.

How to Check If a Dependency Includes a Manifest

For CocoaPods, check if the pod's bundle includes PrivacyInfo.xcprivacy:

find Pods/ -name "PrivacyInfo.xcprivacy" -type f

This shows which pods ship a privacy manifest. Any pod that references Required Reasons APIs but is missing from this list is a problem.

For Swift Package Manager (SPM), the manifests are embedded in the package's resource bundle. Check the derived data:

find ~/Library/Developer/Xcode/DerivedData/ \
  -path "*/SourcePackages/*" \
  -name "PrivacyInfo.xcprivacy" -type f

The Codesign Verification Trick

After archiving your app, you can extract the full privacy report to see exactly what is declared and what is missing. In Xcode, go to Window > Organizer, right-click your archive, select Show in Finder, then right-click the .xcarchive file and select Show Package Contents. Look for the PrivacyReport inside.

Alternatively, you can generate the privacy report from the command line on an exported .ipa:

unzip -o YourApp.ipa -d /tmp/app_extract
codesign -d --entitlements - /tmp/app_extract/Payload/YourApp.app

And inspect the embedded manifests:

find /tmp/app_extract/Payload/ -name "PrivacyInfo.xcprivacy" -type f

This tells you exactly which frameworks inside your app bundle have (or are missing) privacy manifests.

Fixing Third-Party SDK Issues

  1. Update your dependencies. Run pod update or update your SPM packages to their latest versions. Most major SDKs added privacy manifests by mid-2024.
  2. If the SDK maintainer has not added a manifest, you can create a privacy manifest for the SDK yourself by adding a PrivacyInfo.xcprivacy to the SDK's resource bundle in your project. This is a workaround, not a long-term fix.
  3. Consider replacing unmaintained SDKs. If a dependency has not been updated in over a year and lacks a privacy manifest, it is a liability for your app's review process.

AI/ML Data Sharing Disclosure (Guideline 5.1.2(i))

Starting in late 2025, Apple introduced a new requirement under App Store Review Guideline 5.1.2(i) that applies to apps performing on-device machine learning. If your app uses data from the device — such as photos, text input, health data, or usage patterns — to train, fine-tune, or improve machine learning models (even if the training happens entirely on-device), you must disclose this to the user.

This interacts with the privacy manifest in two ways:

  • NSPrivacyCollectedDataTypes must include entries for any data categories used for ML training. For example, if your app analyzes photos to improve a local recommendation model, you must declare the "Photos or Videos" data type with the "Product Personalization" purpose.
  • App Store Connect metadata must separately declare this data usage in the app's Privacy Nutrition Label.

This requirement is distinct from ITMS-91053 but often surfaces during the same review cycle. If your app uses Core ML, Create ML, or any on-device training framework, audit your privacy manifest's NSPrivacyCollectedDataTypes section alongside the NSPrivacyAccessedAPITypes section.

Catch rejection issues before Apple does

Upload your .ipa or .apk and get an instant compliance report with 45+ automated checks. Free, no signup required.

Scan your app free

Step-by-Step Fix for ITMS-91053

If you are staring at the rejection email right now, follow these steps in order.

1. Create PrivacyInfo.xcprivacy in Xcode

Open your project in Xcode. Select File > New > File. Search for "App Privacy" in the template picker. Select it and add it to your main app target. Xcode creates a PrivacyInfo.xcprivacy file with the correct structure.

Make sure the file is included in your target's Copy Bundle Resources build phase. If it is not, drag it there manually.

2. Identify Which APIs Your Code Uses

The rejection email tells you which API categories are missing. But to get the full picture, search your codebase:

# File timestamp APIs
grep -rn "NSFileCreationDate\|NSFileModificationDate\|creationDate\|modificationDate\|getattrlist\|stat(" . --include="*.swift" --include="*.m"

# System boot time / uptime
grep -rn "systemUptime\|mach_absolute_time\|mach_continuous_time\|ProcessInfo.*uptime" . --include="*.swift" --include="*.m"

# Disk space
grep -rn "volumeAvailableCapacity\|volumeTotalCapacity\|statfs\|statvfs" . --include="*.swift" --include="*.m"

# User defaults
grep -rn "UserDefaults\|NSUserDefaults\|standardUserDefaults" . --include="*.swift" --include="*.m"

# Active keyboards
grep -rn "activeInputModes" . --include="*.swift" --include="*.m"

Run these from your project root. Note that these searches only cover your own source files. Third-party SDKs compiled into frameworks will not show up here — handle those separately (see above).

3. Add Entries to NSPrivacyAccessedAPITypes

Open PrivacyInfo.xcprivacy in Xcode. For each API category your code or its dependencies use, add an entry to the NSPrivacyAccessedAPITypes array. Each entry needs:

  • NSPrivacyAccessedAPIType — The category string (e.g., NSPrivacyAccessedAPICategoryUserDefaults).
  • NSPrivacyAccessedAPITypeReasons — An array of reason code strings (e.g., ["1C8F.1"]).

Pick the reason codes that accurately describe how your app uses the API. Do not add reason codes that do not apply to your use case — Apple reviewers may question them. But do include all reason codes that are relevant. You can declare multiple reasons per category.

4. Update Third-Party SDKs

Update all your dependencies to their latest stable versions:

# CocoaPods
pod repo update && pod update

# Swift Package Manager
# In Xcode: File > Packages > Update to Latest Package Versions

After updating, verify that privacy manifests are present:

find Pods/ -name "PrivacyInfo.xcprivacy" | sort

If a critical dependency still lacks a manifest, create one for it manually and include it in the dependency's resource bundle within your project.

5. Validate Locally with Xcode's Privacy Report

Build your app for archiving (Product > Archive). Once the archive completes, open the Organizer (Window > Organizer), right-click the archive, and select Generate Privacy Report. Xcode produces a PDF showing every API category declared across your app and all its embedded frameworks.

Review the report to confirm:

  • Every API category flagged in the rejection is now declared.
  • The reason codes match your actual usage.
  • Third-party frameworks have their own declarations.

6. Upload to App Store Connect and Verify

Archive your app again and upload it via Xcode or Transporter. After processing (usually 10-30 minutes), check your email and App Store Connect for any new ITMS warnings. If the build processes without privacy manifest warnings, you are clear to submit for review.

If you still see warnings, compare the specific API categories mentioned against your privacy report. The most common oversight is a transitive dependency (a dependency of a dependency) that references Required Reasons APIs without a manifest.

Prevention Checklist

Keep this list in your release workflow to avoid ITMS-91053 on future submissions:

  • Always include PrivacyInfo.xcprivacy in your main app target. Treat it as a mandatory file, like Info.plist.
  • Update dependencies before every release. Run pod update or update SPM packages to pick up privacy manifest additions from SDK maintainers.
  • Generate the Xcode Privacy Report on every archive. Make it part of your pre-submission checklist. It takes 30 seconds and catches problems before Apple does.
  • Audit new dependencies for privacy manifests. Before adding a new SDK, check its documentation or repository for PrivacyInfo.xcprivacy.
  • Pin dependency versions intentionally. If you must pin to an older version, verify that version includes a privacy manifest. If not, create one manually.
  • Search for Required Reasons API usage when adding new features. A single call to UserDefaults or stat() in new code requires a manifest entry.
  • Test with TestFlight before submitting for review. TestFlight processing runs the same automated checks as production submission. Use it as a dry run.
  • Keep your privacy manifest in version control. Track changes to PrivacyInfo.xcprivacy in git so you can trace when entries were added or removed.
  • Monitor Apple developer news. Apple periodically adds new Required Reasons API categories and updates enforcement timelines. Subscribe to the Apple Developer News feed.
  • Use automated validation tools. Upload your .ipa to a pre-submission validator that checks for privacy manifest completeness before you send it to Apple.

Getting rejected is frustrating, but the fix is mechanical. Create the manifest, declare your reasons, update your SDKs, and verify with a privacy report. The whole process takes 15-30 minutes once you know what to look for.