All packsApp Store MachinerySolve
ios privacy manifest required reason api missing
Xcode lets you submit without the privacy manifest Apple requires
A missing or incomplete PrivacyInfo.xcprivacy -- including required-reason API declarations buried in a long Apple enum -- compiles fine and gets rejected days later.
What goes wrong
Apple requires an app-level PrivacyInfo.xcprivacy manifest declaring collected data types and any use of "required-reason" APIs (things like UserDefaults or checking system boot time), each keyed to a specific reason code from a long, easy-to-miss enum in Apple's documentation. Xcode does not block a build or archive that's missing this file or missing a required reason code -- the app submits, builds, and then gets rejected by App Review days later for a static, checkable omission nothing in the toolchain flagged earlier.
Why agents get it wrong
Nothing about a missing PrivacyInfo.xcprivacy file breaks compilation, a local run, or TestFlight distribution -- every normal development signal says the app is fine. The specific required-reason codes (like CA92.1 for UserDefaults) are documented in a long Apple reference table that has to be consulted deliberately; there's no compiler warning connecting "this app reads UserDefaults" to "this specific reason code is now required in the manifest."
What App Store Machinery pre-decides
Decision 14 pre-fills the app-level manifest with the three required-reason APIs the pack's own code actually uses -- UserDefaults (CA92.1), FileTimestamp (C617.1), SystemBootTime (35F9.1) -- plus the purchase-history data-type declaration the appAccountToken join requires, and marks tracking as false with no tracking domains. The review-rejection preflight lane statically lints for the file's presence and correctness before the build ships, catching what Xcode itself doesn't.
Source: ARCHITECTURE.md decision 14