There's a specific kind of frustration that comes from an App Store rejection you didn't see coming.
Not a crash. Not a guideline violation. Not a metadata problem. Just a cold rejection email with an error code — ITMS-91053 — and a list of APIs your app called without declaring a reason for calling them.
APIs you've used for years. APIs that work perfectly. APIs like UserDefaults.
What Changed and Why It Matters
Starting May 1, 2024, Apple began enforcing a requirement that had been announced but, frankly, underestimated by a lot of developers: every app must ship with a PrivacyInfo.xcprivacy privacy manifest file. And if that app — or any SDK it bundles — touches certain system APIs without declaring a reason, the submission is rejected outright.
No warning. No grace period. Just a rejection and a list of undeclared APIs.
The requirement exists for a good reason. Third-party SDKs — analytics tools, crash reporters, ad networks — have always had the ability to call sensitive system APIs silently, without any visibility at the app layer. Developers trusted the SDK and moved on. Apple decided that transparency needed to be enforced, not just encouraged.
That's fair. The implementation, though, catches a lot of developers off guard — because the APIs on the required reasons list aren't obscure. They're everyday tools.
The Five APIs That Are Blocking Submissions
Apple currently defines five categories of required reason APIs. If your app uses any of these, you must declare it in your privacy manifest with a specific reason code:
File Timestamp APIs — creationDate, modificationDate, getattrlist(). If you read file metadata anywhere in your app, this applies.
System Boot Time APIs — mach_absolute_time(), systemUptime. Used for timing events, measuring elapsed time, calculating absolute timestamps. More common than you'd think.
Disk Space APIs — volumeAvailableCapacityKey, statfs(). If your app checks available storage before downloading or writing files, you're calling these.
Active Keyboard APIs — activeInputModes. Narrower use case, but catches keyboard-aware UI work and custom keyboard apps.
UserDefaults — The entire UserDefaults class. This is the one that gets almost everyone. Feature flags, user preferences, shared app group settings, SDK internal state — it's all UserDefaults. If your app runs on iOS, it almost certainly uses this.
For each category, you don't just declare that you use it — you declare why you use it, using a specific reason code from Apple's list. CA92.1 means you're reading defaults within your own app. 1C8F.1 means you're accessing a shared app group container. The codes are precise, and picking the wrong one is as much of a problem as not declaring at all.
The Part That Surprises Developers Most
Your own code is only half the story.
Every third-party SDK your app bundles is your responsibility. If Firebase, Amplitude, your crash reporter, or any other SDK on Apple's commonly-used list ships without a privacy manifest — or ships with an outdated one — your submission fails. Even if your own PrivacyInfo.xcprivacy is perfectly complete.
The safest move before every archive: update all your dependencies to their latest versions, then run Product → Privacy Report in Xcode. This generates a combined PDF of every manifest in your app bundle. Any SDK missing a manifest simply won't appear in the report. That absence is your signal to investigate before submitting — not after.
I've seen a particular edge case with static CocoaPods where the manifest file exists in the repository but doesn't get correctly bundled by Xcode due to how static library resources are handled. In those cases, the fix is to manually copy the SDK's required API declarations into your own PrivacyInfo.xcprivacy. Inelegant, but it works.
It's A One-Time Investment
Once your manifest is in place and your SDK dependencies are updated, the ongoing maintenance is light. Before each release: check for new API usage you've added, verify any newly integrated SDKs, regenerate the Privacy Report. Five minutes at most.
The harder part is the first time — understanding which categories apply to your app, reading each reason code carefully to pick the right one, and auditing every SDK in your bundle. That's where most of the time goes.
Apple has also signalled that this list of required reason APIs can expand in future OS releases. Treating it as a living compliance checklist — rather than a one-time fix — is the right posture.
I documented the full process: all five API categories, every reason code table, the SDK verification workflow, a 9-point pre-submission checklist, and the common mistakes that cause re-submissions.
If you're shipping an iOS app and haven't looked at your privacy manifest yet, this is the place to start.
Read the full article in idiotswithios.com
Top comments (0)