ITMS-91053 — Missing API declaration

Step 1 — read the email properly

Two pieces of information are in it and both matter.

The file. If it names your app's main binary, the usage is being attributed to code compiled into your app target — which for an RN app includes statically linked pods. If it names a framework inside Frameworks/, the responsible bundle is that framework and the fix is upstream.

The category. There are exactly five, and each has its own set of approved reason codes:

Step 2 — find which bundle is responsible

Start with what already ships a manifest:

find node_modules -name "PrivacyInfo.xcprivacy" | sed 's|node_modules/||' | cut -d/ -f1 | sort -u

Then check the same for the built app, because this is where static linking hides things:

find "$(xcodebuild -showBuildSettings 2>/dev/null | awk -F'= ' '/BUILT_PRODUCTS_DIR/{print $2}')" \
  -name "PrivacyInfo.xcprivacy" 2>/dev/null

And cross-reference against Apple's published SDK list. Any package on that list must ship a manifest and a signature. The RN/Expo-relevant subset of Apple's list.

Step 3 — fix it in the right place

There are only three legitimate fixes, and choosing the wrong one produces a rejection that looks fixed.

If the usage is in a third-party dependency: update the package. Most maintained libraries added PrivacyInfo.xcprivacy during 2024. If the package is unmaintained and has not, your options are to fork it and add the manifest, replace it, or remove it. You cannot declare on its behalf — Apple states a third-party SDK "can't rely on the privacy manifest files for apps that link the third-party SDK."

If the usage is genuinely in your own app code: add the category to your app's PrivacyInfo.xcprivacy with an accurate reason.

<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array>
      <string>CA92.1</string>
    </array>
  </dict>
</array>

If you are in Expo with CNG: the manifest is generated, so hand-editing ios/ is overwritten on the next prebuild. Configure it through app.json/app.config.js or a config plugin so the value survives.

Step 4 — pick the reason code accurately, not defensively

The most common mistake after the first rejection is declaring every code in the category. That is a misdeclaration. Apple's wording is that you must declare reasons that "accurately reflect your use," and that you "may use these APIs and the data derived from their use for the declared reasons only."

Several codes bind you to conditions once declared:

• DDA9.1, 85F4.1, 35F9.1, 3EC4.1, 54BD.1 and CA92.1 all carry "may not be sent off-device" language in some form.
• E174.1 requires the app to behave observably differently based on disk space.
• 3EC4.1 requires that a systemwide custom keyboard is the app's primary functionality.
• 0A2A.1 and C56D.1 may only be declared by third-party SDKs.

The normal, accurate declarations for an ordinary React Native app are CA92.1 for UserDefaults, C617.1 for file timestamps in your own container, and 35F9.1 for boot time used to measure in-app elapsed time.

The complete category and reason-code reference, transcribed from Apple's rendered docs.

Why this one costs so much calendar time

An ITMS-91053 email arrives after an upload, not after a review. So the loop is: build, upload, wait, read the email, guess at which of several hundred packages is responsible, change something, build again. Each iteration is a full EAS build and upload. Two or three iterations is a week gone, and the feedback contains a category name but not a package name.

This is precisely the class of problem shipcheck exists for: it reads node_modules, the built products directory, and every PrivacyInfo.xcprivacy in the tree before you build, and reports which bundle is missing which declaration, with the clause behind it. What shipcheck is and how to run it.

Related codes

ITMS-91061 in detail.

Questions and answers