← iOS Privacy Manifest Checker
Apple's documentation names the five Required Reason API categories and
the reason codes it publishes for each -- it is the source of truth this
tool's own category and code list is checked against. What it does not do
is read your specific source files or your specific
PrivacyInfo.xcprivacy and tell you which category you
actually triggered, in which file, or whether the code you declared is
even valid for that category. That cross-check has always meant either a
guess informed by the docs, or a definite answer from an
ITMS-91061/ITMS-91055 rejection days
later.
Apple's documentation is complete and authoritative about
what the categories and codes are. It is not a scanner: it cannot look at
your project and tell you that DiskSpaceChecker.swift line 6
calls systemFreeSize with no matching manifest entry, because
it has never seen your code.
App Review will eventually tell you, with certainty -- after a submission, a review cycle, and a rejection naming the exact code. For a Required Reason API call buried inside a third-party SDK's compiled binary rather than your own source, that rejection may be the first time anyone on the team learns the dependency uses one at all.
This checker runs the same category-and-code cross-check App Review runs, against your source and manifest, before you submit -- in the browser (nothing uploaded) or as a Node CLI you can gate CI on.
| Question | Where to answer it |
|---|---|
| Which category does my code trigger, and where? | This checker's scan -- file and line, free, nothing uploaded. |
| What are the valid reason codes for a category? | This checker lists them per category; both it and Apple's docs agree, since this tool's list is checked against Apple's published one. |
| Will App Review actually approve my build? | Neither. Only Apple's own review determines that -- this is evidence about your source and manifest as they stand today. |
| Is my source code uploaded anywhere? | No. The browser tool reads files with the File API; the CLI never makes a network call. |
It lists the five Required Reason API categories and the published reason codes for each, and it is the source of truth this tool's own category and code list is checked against. What it doesn't do is read your specific source files or your specific PrivacyInfo.xcprivacy and tell you which category you actually triggered, in which file, on which line, or whether the code you declared is even one of the valid ones for that category. That cross-check is what used to mean either guessing from the docs or finding out from a rejection.
A submission-review-rejection cycle, at minimum -- often a day or more before ITMS-91061 or ITMS-91055 comes back, and then the same wait again after the fix. For a category buried in a third-party SDK's compiled binary rather than your own code, the first rejection may be the only way you learn the SDK uses a Required Reason API at all. Scanning your source and manifest before you submit catches the same defect without spending a review cycle to find it.
You can, and for a small project it may be faster than downloading a tool. The risk is coverage: five categories, each with several trigger symbols (stat(), systemUptime, UserDefaults, and more), across every .swift, .m, .mm, and .h file in the project plus whatever a dependency's own compiled binary calls -- Apple's own review checks the compiled symbol table, not just the files you remembered to grep. This tool runs the same symbol list against every file you point it at, in the browser or as a CI-gating CLI, so a category buried in a file you didn't think to check is not the one that reaches App Review first.
No, and it is not built to. This is pattern-matching against known API symbol names in the source and manifest you point it at -- it cannot see reflection, dynamically loaded code, or the internals of a third-party SDK's compiled binary, and Apple can add categories or reason codes at any time. A clean report means your current source and manifest agree with each other and with Apple's published list; it is not a guarantee App Review will pass, so verify against Apple's current documentation before you submit.