Documentation iOS · Menu
iOS release-readiness checks
iOS review is dominated by one problem: the expensive failures are administrative rather than technical. A missing declaration costs a review cycle, and you find out days after the engineering work was finished.
Detection
Run detection from the application directory. Guardian reports the platform it found and the analysis paths that apply before any analysis runs.
guardian detect .Configuration and metadata
Guardian reads the release configuration and the metadata that describes what the application declares about itself. That is where privacy purpose declarations and transport settings live, and it is the area where a mechanical check pays for itself most often.
| Area | Why it is read |
|---|---|
| Release metadata | Declared capabilities and the purpose text that must accompany privacy-sensitive ones. |
| Transport configuration | Whether the release build permits unencrypted traffic beyond a documented exception. |
| Dependency declarations | The inventory of what the application is built from. |
Each of these is documented individually, with its own status, in thechecks catalogue.
What stays local
No account, no upload, and no network requirement for local analysis. Seesecurity and privacy for the complete boundary.
Current limits
- Individual iOS checks are in preview. Do not read the presence of a category as a guarantee that a specific rule exists — the catalogue states each one.
- Signing validation, privacy manifest checks and store-submission verification are not published capabilities. Where they appear in the catalogue they are marked as planned.
- Guardian does not submit, validate against, or predict the outcome of platform review. It catches the mechanical problems beforehand.
- A capability declared by a dependency rather than by your own code will still be reported. That is usually worth knowing, but it means a finding is not always about code you wrote.