An iOS project can contain PrivacyInfo.xcprivacy and still have an incomplete release review. Checking the application's own files overlooks SDKs embedded in the submitted archive, indirect dependencies and configuration-dependent behavior.
Start with the exact archive intended for distribution, inventory its components, and assign an owner to each unresolved declaration. Privacy manifests, App Store privacy information and the public privacy policy describe related parts of a product; they are not interchangeable documents.
Inventory what the release actually contains
Apple identifies third-party SDK requirements, including manifest and signature obligations for the cases described in its current guidance. Check that guidance for the release you are preparing rather than relying on a remembered list.
Do not inspect only packages explicitly added by your team. A direct dependency may introduce another SDK. Build configuration and enabled features may also change the distributed components. Retain the lockfile, build-tool version and relevant feature configuration beside the release candidate.
Assign responsibility before editing declarations
Consider a hypothetical learning app using crash reporting, purchases and optional behavioral analytics. Calling all three components non-collecting because your team did not write their networking code would be an unsupported conclusion. Review the provider documentation and actual SDK configuration.
| Component | Record | Useful evidence |
|---|---|---|
| Application code | Relevant API use and purpose | Call site, configuration and responsible engineer |
| Direct SDK | Version and operating mode | Lockfile and provider documentation |
| Indirect SDK | Dependency that introduced it | Dependency tree for the release build |
| Manifest | Presence in the distributed product | Inspection of the actual archive |
| Public disclosure | Data, purposes and choices | Policy and store answers for the same build |
An unresolved field is more useful than a confident answer without evidence. Give each unresolved item an owner and a release decision, rather than treating the inventory as a form to complete at any cost.
For example, an analytics component disabled in the interface may still be initialized by startup code. The review should establish whether its configuration changes collection behavior, not merely whether a settings switch appears off.
Choose required reasons from actual use
Apple documents API categories requiring reasons and the accepted purposes associated with them. Match a declaration to what your product or component actually does. A reason copied from a discussion thread is not automatically appropriate to another application.
When a dependency introduces relevant API use, investigate the SDK version and provider guidance. An update or a provider clarification may be the appropriate next step. Adding a reason you do not understand simply to remove a warning leaves the underlying question unresolved.
Keep a short decision record: the component, its purpose, the reference checked and the person who verified the relationship. Avoid including customer data in that record; this is evidence about software behavior, not a collection of production payloads.
Use a repeatable archive review
- Freeze the source revision, lockfile and feature configuration.
- Produce the archive through the real release process.
- Inspect the packaged manifests and applicable privacy reports from Apple's tools.
- Compare embedded SDKs with the current published requirements.
- Review relevant API purposes, data categories and tracking configuration.
- Reconcile the result with the public policy and store privacy information.
Document the limits of each observation. Watching one session does not prove that an SDK never transmits data. Collection may depend on a purchase, a crash, consent state or an optional feature. Include representative scenarios for the components you actually ship.
Decide what blocks the release
Stop to clarify an unknown SDK behavior, a required component missing from the archive or a contradiction between public statements and observed configuration. A warning disappearing is not the same as establishing an accurate declaration.
Retain the review by release version. When a dependency changes, compare the affected responsibilities instead of starting a new checklist that loses the earlier reasoning. If a component is removed, confirm that its related declarations and public explanations are revisited as appropriate.
This review fits into the wider mobile release-readiness process. For organizing the underlying data inventory, use the privacy-first analytics guide.
Frequently asked questions
Does a privacy manifest replace the privacy policy?
No. Technical metadata and public explanations serve different purposes. Both should remain consistent with the product's real behavior and current platform requirements.
Does adding the file guarantee App Store approval?
No. Review depends on the submitted product and applicable requirements. A manifest is one part of release preparation, not an approval certificate.
Primary sources
Check these original references again before making a release or policy decision.