App Rejection Fix
App Store Medium Rejection

Missing privacy manifest or required-reason API declaration

The build uses required-reason APIs or listed SDKs without the privacy manifest declarations Apple expects (ITMS upload warnings or rejection).

Typical wording

ITMS-91053: Missing API declaration - Your app's code in the "App" file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp, NSPrivacyAccessedAPICategoryUserDefaults.

Common causes

  • A third-party SDK on Apple’s list (Firebase, Facebook, Alamofire, Flutter/RN plugins …) at a version without PrivacyInfo.xcprivacy
  • App code using required-reason APIs (file timestamps, UserDefaults, system boot time, disk space, active keyboards) without declared reasons
  • An app-level privacy manifest that is missing, not in the main bundle, or not copied by the build
  • Outdated CocoaPods / Swift Package dependencies pinned by an old lockfile

What to check

  • The API categories and SDK names listed in the ITMS email
  • Podfile.lock / Package.resolved versions against each vendor’s first manifest-bearing release
  • Whether PrivacyInfo.xcprivacy is in the app target and each framework target that needs one
  • The generated privacy report in Xcode (Archive → Generate Privacy Report)

Fix, reply or appeal guidance

  • Upgrade every listed SDK to a version that ships a privacy manifest and signature
  • Add PrivacyInfo.xcprivacy to the app with the approved reason codes for each API category the app itself uses
  • Fill NSPrivacyCollectedDataTypes and NSPrivacyTracking so they match the App Store privacy details
  • Rebuild with Xcode 26, generate the privacy report, re-upload and confirm no ITMS email arrives

What the ITMS-91053 email actually says

After a successful upload, App Store Connect emails “ITMS-91053: Missing API declaration” listing one or more API categories — file timestamp APIs, UserDefaults, system boot time, disk space, active keyboard list — and, since Apple’s SDK requirements took effect on 1 May 2024, it can also name third-party SDKs that ship without a privacy manifest or signature. The email is a warning while the build is still processed; the same conditions can block a new app or an update that adds a listed SDK, so treat it as a defect to fix before the next submission rather than noise.

Where the missing declaration usually is

  • The app itself — any use of the listed API categories needs an approved reason code in the app’s PrivacyInfo.xcprivacy under NSPrivacyAccessedAPITypes. Reading a file modification date or using UserDefaults is enough to trigger the category.
  • A dependency — Apple lists the commonly used SDKs that must carry their own manifest (networking, analytics, Firebase modules, Facebook SDKs, Flutter and React Native plugins such as file_picker, device_info_plus, connectivity_plus, and many more). Versions released before 2024 typically have none; the lockfile decides which version is really in the build.
  • The build — a manifest that exists in the repository but is not a member of the target, or a framework target whose manifest is not copied, produces the same warning.

Fixing it, step by step

  1. Read the email carefully: each API category maps to a set of approved reason codes; each named SDK maps to a version upgrade.
  2. Update dependencies to the vendor’s first manifest-bearing release (pod update / Swift Package update / flutter pub upgrade / npm update plus the native install step) and confirm in Podfile.lock or Package.resolved.
  3. Add or complete the app’s PrivacyInfo.xcprivacy: accessed API types with reasons, collected data types, and the tracking flag and tracking domains if the app tracks.
  4. Archive in Xcode 26 and use Generate Privacy Report — it aggregates every manifest in the build and shows what is still undeclared.
  5. Re-upload. No ITMS-91053 email means the declarations are complete; if App Review later asks about a reason, the privacy report is your evidence.

Why it matters beyond the email

The manifest declarations feed the App Store privacy details (“nutrition labels”). A manifest that says the app collects nothing while an analytics SDK’s manifest says otherwise is exactly the inconsistency that produces Guideline 5.1 privacy rejections. Fixing the manifest and re-checking the privacy details together avoids a second round.

Framework notes

  • Flutter: the engine ships a manifest; each plugin with iOS code needs one — upgrade plugins, then check the privacy report; a plugin can be manifest-free and still be fine if it uses no listed API.
  • React Native: core ships a manifest; native modules and pods pinned by an old Podfile.lock are the usual culprits.
  • Unity: recent Unity versions include a manifest for the engine; third-party native plugins must be updated individually.

Uploads that fail for toolchain reasons rather than manifests — the Xcode 26 / iOS 26 SDK requirement in force since 28 April 2026 — are covered on the legacy app update page; the dated requirements are on app publishing deadlines.

Read the detailed guide: Privacy Rejection (5.1) →