Apple Privacy Manifests in 2026: The Required Reason API Checklist

Apple's privacy manifest requirement has been in force since May 1, 2024, and it remains one of the few submission failures that has nothing to do with how your app behaves — a build that uses a required reason API without a declared reason is simply not accepted by App Store Connect. Two separate obligations live in the same file: the data-collection declarations, which apply on all platforms, and the required reason API declarations, which apply on iOS, iPadOS, tvOS, visionOS and watchOS. If your app links one of the SDKs on Apple's commonly used SDK list, that SDK's own manifest and signature are required on top. These are the twelve checks we run before an archive leaves the Mac.

1. Is a manifest actually required for this app?

Two obligations decide that, and their scope differs. Data collection declarations are needed for your app or third-party SDK on all platforms. Required reason API declarations are needed on iOS, iPadOS, tvOS, visionOS and watchOS. If the app 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, it needs the file. If it is one of the listed SDKs, it needs one regardless.

2. Does the file have the exact name, and is it in the bundle?

PrivacyInfo.xcprivacy is the required file name — Apple rejects any other. In Xcode: File > New File, scroll to the Resource section, pick the App Privacy File type, tick your target, and create it. Then confirm it is listed in that target's resources, because Xcode only uses a manifest it finds there when it generates the privacy report. If you ship a third-party SDK as a static library, use the static framework support added in Xcode 15 and add the manifest to the framework target's bundle resources alongside the other resources.

3. Are all four top-level keys present?

• NSPrivacyTracking — whether the app or third-party SDK uses data for tracking.
• NSPrivacyTrackingDomains — the domains contacted for tracking.
• NSPrivacyCollectedDataTypes — one dictionary per type of data collected, each reporting the data type, whether it is linked to the person's identity, whether it is used for tracking, and the purposes.
• NSPrivacyAccessedAPITypes — one dictionary per required reason API category, each reporting the category and its reason codes.

If the app does not track, say so explicitly in the file rather than omitting the tracking keys.

4. Have you audited all five required reason API categories?

Apple groups the regulated APIs into five categories. Audit the code you wrote and, separately, the code inside every SDK you link — a single call is enough to make the declaration necessary:

• File timestamp — getattrlist, getattrlistbulk, fgetattrlist, fstat, fstatat, lstat, getattrlistat.
• System boot time — mach_absolute_time().
• Disk space — statfs, statvfs, fstatfs, fstatvfs, plus the getattrlist family.
• Active keyboards — the APIs that report which keyboards are active on the device.
• User defaults — reads and writes through the user defaults APIs.

5. Does every entry use an approved reason code?

Reason codes are fixed strings Apple publishes; you choose from the list, you do not write your own. The ones we declare most often: file timestamps — DDA9.1 (display timestamps to the person using the device), C617.1 (files inside the app, app group or CloudKit container), 3B52.1 (files or directories the user specifically granted, such as through a document picker), 0A2A.1 (a third-party SDK wrapping the API for the app). System boot time — 35F9.1 (measure elapsed time between events in the app, or to run timers), 8FFB.1 (absolute timestamps for events that occurred in your app), 3D61.1 (boot time inside an optional bug report the person submits). Disk space — 85F4.1 (display disk space to the person using the device), E174.1 (check there is enough space to write, or free space when it runs low), 7D9E.1 (disk space inside an optional bug report), B728.1 (health research app). User defaults — CA92.1 (data accessible only to the app itself), 1C8F.1 (app, app extensions and App Clips), C56D.1 (SDK wrapper, third-party SDKs only), AC6B.1 (MDM-managed configuration keys). Active keyboards — 3EC4.1 (custom keyboard app), 54BD.1 (present the correct customised interface).

6. Do the reasons match functionality users can see?

Each reason carries its own conditions, and reviewers read them. E174.1 requires the app to behave differently depending on disk space in a way that is observable to users. 3EC4.1 is reserved for apps whose primary functionality is a systemwide custom keyboard. 3D61.1 requires the boot time to be prominently displayed as part of a report the person chooses to submit. Pick the reason that describes what the code really does; the declared reasons must also be consistent with the functionality you present to users.

7. Have you stopped every transfer the reason forbids?

Declaring a reason licenses the API use and the data derived from it for that reason only. Most reasons carry the sentence that the information, and anything derived from it, may not be sent off-device. The documented exceptions are narrow: elapsed time between in-app events may leave the device (35F9.1); absolute in-app timestamps may leave (8FFB.1) but the boot time itself may not; bug-report values may leave only after the person affirmatively submits that specific report; and disk space may cross the local network to another device used by the same person for display, never over the internet. Analytics SDKs are where this rule breaks first, so check what they upload before you sign the declaration.

8. Is the tracking declaration consistent?

Fingerprinting is prohibited whether or not the person granted tracking permission, and you may not use these APIs or the data derived from them for tracking. If the answer is no tracking, put that in the file — an explicit false is a declaration, silence is not.

9. Whose manifest covers the SDK?

The SDK's own. A third-party SDK cannot rely on the manifest of the app that links it, or on those of other SDKs the app links. Every executable or dynamic library in an app that uses a required reason API needs a bundle containing a manifest that reports it. The mirror-image rule is friendlier: your app's privacy manifest does not have to cover data collected by the third-party SDKs your app links to.

10. Have you checked the SDK list and its signatures?

The privacy manifest is mandatory for any SDK on Apple's list when you submit a new app that includes it, or an update that adds one of the listed SDKs — and signatures are additionally required where those SDKs are used as binary dependencies, so Xcode can validate that the SDK was signed by the same developer. Every version of a listed SDK is in scope, and so is any SDK that repackages a listed one. The list hits most real-world stacks: Flutter and its common plugins, FirebaseCore, FirebaseMessaging, FirebaseCrashlytics, OneSignal, Alamofire, SDWebImage, Reachability, nanopb, GoogleUtilities, UnityFramework and hermes among them. When one of these quarantines an upload, the fix is usually a version bump to a release that ships its own manifest and signature.

11. Can you produce the privacy report before upload?

Open the project in Xcode, choose Product > Archive, then control-click the archive in the Organizer and choose Generate Privacy Report. Xcode aggregates your manifest with the manifests of every SDK the app links to. Read that report before you fill in the privacy details in App Store Connect, not after — it is the same picture the reviewer sees.

12. What happens if you upload without it?

First an email: Apple sends a reminder to add the missing reason to the app's privacy manifest. Then the hard stop — since May 1, 2024, apps that do not describe their use of required reason API are not accepted by App Store Connect. There is no review queue for a build that fails this validation, and a large portfolio feels it immediately, because the same recurring API use shows up in every package.

Sources

• Apple Developer — Privacy manifest files: developer.apple.com/documentation/bundleresources/privacy-manifest-files
• Apple Developer — Describing use of required reason API: developer.apple.com/documentation/bundleresources/describing-use-of-required-reason-api
• Apple Developer — Describing data use in privacy manifests: developer.apple.com/documentation/bundleresources/describing-data-use-in-privacy-manifests
• Apple Developer — Third-party SDK requirements: developer.apple.com/support/third-party-SDK-requirements