Privacy Manifest Review for a Local AI App

Direct answer

A privacy manifest is a declaration included in a build, not a live network monitor. Apple describes PrivacyInfo.xcprivacy as a property list reporting data collected by an app or third-party SDK and, for applicable platforms, required-reason APIs. An archive may contain several manifests across app targets and SDKs, and Xcode can generate an aggregate report. This is useful review evidence, but it does not prove every conditional feature or runtime request. PRIVACY-01 and ANDROID-PRIVACY-01 support evidence-led boundary review; this guide concerns Apple bundle inspection, not a claim that Cove ships an Apple app or has a complete manifest. Start with the exact archive. Record Xcode version, build configuration, app target, extensions, embedded frameworks, package lockfiles, and archive identity. A debug archive, simulator build, and distribution archive can contain different targets and dependencies. Inspect the final archive rather than only the source tree. Enumerate every PrivacyInfo.xcprivacy file by bundle path and owning target. A missing file means only that no declaration was found in that inspected bundle; it does not prove that the app does not access or transmit data. Review each manifest’s data categories, purposes, tracking settings and domains, and required-reason API entries. Map each declaration to the code or SDK that uses it. Apple distinguishes app and SDK responsibilities and expects required-reason declarations to correspond to actual use. Do not copy a reason from a vendor example merely because a symbol appears in code search. If an SDK has its own manifest, keep it with dependency evidence and verify the archived version contains it. Resolve dependencies before comparing claims. Record package identity, version, origin, source or binary distribution, transitive path, signature information where relevant, and the vendor documentation revision. A manifest can be missing, outdated, malformed, or inconsistent with an updated SDK. A valid manifest is still only a declaration. Check for repeated SDK copies, optional modules, extensions, plugins, and additional executables in the archive; each may bring its own declaration or required-reason API use. Create a mapping row for each declaration: manifest path, owning target, data category or API reason, implementing component, feature trigger, build condition, reviewer, and unresolved questions. Compare declarations with source search and build settings. If an API is declared but no call is obvious, inspect generated code, framework behavior, reflection, or conditional compilation before editing the manifest. If code appears to use a required-reason API without a declaration, keep the discrepancy open and assign an owner. Do not turn a static report into a claim about every network destination. A tracking-domain entry has a specific meaning under Apple definitions; it is not a universal endpoint inventory. A declared data category also does not establish whether data is linked to identity or retained on every route. Do not apply Apple manifest results to Android or Google Play submissions. Platform, target, and archive version must be named. The review record should include archive identity, date, Xcode and configuration, targets, SDK versions, manifest inventory, declaration-to-code links, mismatches, and separate runtime tests. State narrowly what the archive declares and what code review observed. Do not claim the manifest proves no information leaves the device or proves legal compliance. If a declaration or path remains unexplained, label it unknown and assign follow-up. Repeat after changes to SDKs, targets, build settings, or privacy-sensitive features. This makes one release’s declaration artifact reviewable without confusing declarations with observed behavior.

An archive includes a new SDK privacy manifest

A reviewer receives an Apple distribution archive after a dependency update. It contains a privacy manifest from a newly added SDK and another for the app target. The reviewer needs to check whether declarations match the packaged code without assuming that the plist describes every runtime request.

Decision

Inspect the actual archive and SDK version, map declarations to code and ownership, and test runtime behavior separately where needed.

Expected outcome

The review records bundle-scoped declarations and unresolved questions without claiming complete runtime privacy.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Manifest and dependency inventory
• Traffic and storage evidence
• Disclosure change record

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Pin archive identity and targets. Record Xcode, build configuration, app target, extensions, frameworks, dependency lockfiles, archive identity, date, distribution channel, and reviewer in writing consistently.
2. Inventory manifests in the bundle. Locate every PrivacyInfo.xcprivacy file and record its bundle path, owning app or SDK, version, target, signed binary relationship, and inspected archive hash.
3. Map declarations to code owners. For each data category, purpose, tracking domain, and required-reason API, identify its implementing feature, SDK, code owner, and evidence link.
4. Resolve omissions and mismatches. Compare manifests with dependency versions, source searches, generated code, and conditional targets; keep unexplained differences open for review with an assigned owner.
5. Separate static and runtime evidence. Run separate network or storage tests for behavior and report their feature coverage apart from the archived declaration review for each target.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The record names the archive, build configuration, bundle paths, manifest owners, and exact SDK versions reviewed.
• Every declaration maps to implementation evidence or stays explicitly unknown with an assigned follow-up.
• Conclusions describe manifest declarations and do not claim complete runtime traffic visibility or legal compliance.

Decision table

Failure patterns to prevent

• Using declarations as runtime proof
• Omitting optional SDK paths

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• Apple privacy manifest files
• Apple third-party SDK requirements
• Apple required-reason API declarations

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions