Apple rejected roughly 1 in 8 App Store submissions last quarter for privacy manifest violations. That's not a rounding error. That's a queue of indie devs waiting an extra review cycle because a third-party SDK didn't declare what it does.

the news#

The numbers came out of Apple's Q1 review data: ~12% of submissions bounced on PrivacyInfo.xcprivacy issues. Missing manifests, unsigned SDK manifests, mismatches between what the manifest says and what the app actually calls — all of it gets flagged now. And Apple's tooling has gotten sharper. The binary gets scanned, the reason-code strings get validated, and if your networking SDK pings a "required reason API" that isn't declared, the submission dies.

Most rejected devs I've talked to didn't write the offending code. They pulled in an analytics SDK, a crash reporter, a payments library — and one of those dependencies either doesn't ship a manifest or ships one that doesn't match reality.

why this matters if you're shipping solo#

When you're a two-person team, a rejection isn't just annoying. It's a week. You push the build, wait 24 hours for review, get rejected, dig through the reviewer notes, try to figure out which of your twelve Swift packages is the culprit, update it, rebuild, resubmit, wait another 24 hours. If you're on a launch deadline, that's your launch dead.

The traps are predictable:

SDK vendors who haven't updated their manifest since iOS 17
A fork of an SDK you pulled in two years ago that never had a manifest
Manifests that declare NSPrivacyAccessedAPICategoryUserDefaults with reason code CA92.1 when your SDK actually uses UserDefaults for a different purpose
Your own code touching systemBootTime for a debug log and never declaring it

None of this is hard to fix. It's just hard to find — especially under pressure.

the stora angle#

This is exactly the kind of check we built Stora's compliance engine for. Before you submit, Stora scans your binary, cross-references every required-reason API call against your PrivacyInfo.xcprivacy, and flags the mismatches — yours and every SDK's — with the specific line or symbol causing the problem. If an SDK ships without a manifest, you get told which SDK, not a generic reviewer note three days later.

The build repair agent can also generate the missing manifest entries and surface the reason-code options Apple accepts, so you're not guessing between three plausible strings in the docs.

It doesn't replace understanding the policy. But it catches the class of failures that eat a submission cycle for a reason that has nothing to do with your actual app.

closing#

The privacy manifest rules aren't going away, and they're going to get stricter. If you're shipping iOS apps in 2026, treat the manifest like you treat your Info.plist — a first-class part of the build, not a thing you fill out once and forget. The rejection rate is telling you most people aren't there yet.