A required reason API is one Apple thinks could fingerprint a phone, and an undeclared one stops before a reviewer sees it.

What does Apple mean by a required reason API?

Apple's own framing is about fingerprinting. Some APIs your app uses to deliver its core functionality, in code you write or included in a third-party SDK, have the potential of being misused to access device signals to try to identify the device or user. That is Apple's sentence. It then states the rule that makes the whole thing non negotiable: regardless of whether a user gives your app permission to track, fingerprinting is not allowed. The declaration is read by Apple, not by shoppers on your product page. You tell Apple what you use a risky call for, so the use can be checked against what the app visibly does.

The requirement applies on iOS, iPadOS, tvOS, visionOS and watchOS. Note which platform is absent from that list: macOS. The rest of the privacy manifest, the part describing what data you collect, applies on every platform. Only the required reason half is scoped to those five, and the absence is about the requirement rather than about support, because Apple lists the key itself as available on macOS 14 and later.

Two sentences in Apple's policy aside do real work. You must declare one or more approved reasons that accurately reflect your use of each API and the data derived from it. And you may use those APIs and the derived data for the declared reasons only. Apple adds that your declared reasons must be consistent with your app's functionality as presented to users, and that you may not use the APIs or derived data for tracking. Read that twice if you were planning to pick whichever code looked easiest. Several reasons require behaviour a user can observe, which means the declaration describes your app and not just your build settings.

Scope matters too. For each executable or dynamic library in an app that calls a required reason API, the bundle containing it needs a privacy manifest reporting that API. Apple is blunt that your third-party SDK cannot rely on the privacy manifest files of apps that link it, or of other SDKs in the same app. Whose manifest carries which declaration is the whole subject of the third party sdk privacy manifest rules, which carry their own dated deadline.

Apple, Describing use of required reason API, read 21 October 2026

Which categories does Apple list, and where is the list?

Five categories, read on 21 October 2026: NSPrivacyAccessedAPICategoryActiveKeyboards, NSPrivacyAccessedAPICategoryDiskSpace, NSPrivacyAccessedAPICategoryFileTimestamp, NSPrivacyAccessedAPICategorySystemBootTime and NSPrivacyAccessedAPICategoryUserDefaults. Seventeen approved reason strings sit under them. File timestamps and disk space and user defaults each have four, system boot time has three, active keyboards has two.

Now the thing worth an afternoon of your life. Apple's article titled Describing use of required reason API tells you, in the description of the NSPrivacyAccessedAPIType key, that the value you provide must be one of the values listed in the sections below. On 21 October 2026 that article has no such sections. It contains no category names at all. Technote TN3181 sends you to the same article for possible values. TN3183 does print the five category names, in alphabetical order, but not the reason strings. The one page that carries the categories, the APIs inside each one and the reason strings together is the NSPrivacyAccessedAPIType property list key reference, under a heading called Possible Values. That is where the picker below comes from.

Five is also a snapshot and not a constant. Apple states that it continually reviews the list of required reason APIs and reasons for usage, and will update the article from time to time. It also runs a request form for a new approved reason, for apps that use a covered API to benefit users in a way no listed reason describes. So the honest version of this page is: five categories and seventeen reasons on 21 October 2026, and a list that is designed to grow.

Apple, NSPrivacyAccessedAPIType, Possible Values, read 21 October 2026

What happens if the declaration is missing?

Apple documents two different outcomes and they are worth keeping apart, because people on forums blend them into one. The first is the missing declaration. If you upload an app to App Store Connect that uses a required reason API without describing the reason in its privacy manifest, Apple sends you an email reminding you to add the reason. And since 1 May 2024, apps that do not describe their use of required reason API in their privacy manifest file are not accepted by App Store Connect.

The second is an invalid declaration, which is a manifest that exists but carries unexpected keys or values. Apple's wording there is harder: App Store Connect rejects app submissions that include invalid privacy manifest files. You get an email naming the file and its path inside your bundle, and the error string in it reads ITMS-91056, Invalid privacy manifest. Technote TN3181 lists what counts as invalid, and the common cases are dull: an empty string for the category, an empty reasons array, a reason that does not belong to the category you named. Apple also notes that if you no longer use a category, you remove its dictionary rather than leaving it with an empty array.

There is a documented escape hatch when the bad file belongs to somebody else. If you cannot get a valid manifest out of an SDK developer and you need to ship, Apple tells you to find the invalid manifest in your app archive, delete it, and submit the archive from Xcode. The path comes from the email. You reach it through Window, then Organizer, then Archives, then Show Package Contents in the Finder. Apple warns that removing or modifying the file breaks the archived app's signature, and that Xcode re-signs the app when you distribute the archive from the Archives organizer.

One practical note on finding out cheaply. Apple's trigger for the reminder email is the upload to App Store Connect, and a TestFlight build is such an upload, so you can learn from a build you were going to make anyway. Expo's privacy manifests guide puts the turnaround at a few minutes after submitting. Treat the manifest as a release task rather than a launch task, the same way you would treat the google play data safety form on the other store, because both answers go stale the day somebody adds a dependency.

Is this enforced at upload or at review?

At upload, for the required reason API declaration itself. Apple names the gate in the sentence: not accepted by App Store Connect. App Store Connect is the service your binary lands in. App Review is the human step that comes after you press submit. The required reason check sits in the first one, which is why the feedback arrives as an email from the service rather than a rejection notice with a guideline number on it.

Two neighbouring rules do attach to the submit step, and conflating them with this one is the usual mistake. TN3181 says that starting 12 November 2024, apps you submit for review in App Store Connect must contain a valid privacy manifest file. Apple's page on adding a privacy manifest to your app or third-party SDK says that starting 12 February 2025, apps you submit for review must contain a valid privacy manifest for a certain number of commonly used third-party SDKs, and points at its Upcoming third-party SDK requirements support page for the list. In all three sentences the thing doing the checking is named as App Store Connect. None of them says App Review.

One honest gap. Apple's phrase for a missing reason is that the app is not accepted, and on the pages read on 21 October 2026 it does not say whether the upload itself fails outright or the build is taken and then flagged. For an invalid manifest the wording is firmer, because Apple says submissions are rejected. If you need to know which it will be for your build, the only reliable answer is to upload one and read the email. Rules that bite at submit time behave like the account deletion requirement, which a reviewer can and does check by hand.