What to Do When an iOS Privacy Manifest Is Missing? 2026 Archive Troubleshooting

If App Store Connect reports a missing or invalid privacy manifest, use its error details and file path to identify whether the issue belongs to your app or an embedded SDK. This guide compares the failure types, shows how to inspect the final Archive, and explains what upload validation does—and does not—confirm.

This week, use the App Store Connect error code and component path to decide whether the problem is a missing manifest, an invalid manifest, or a third-party SDK that has not supplied one; then verify the fix in the final Archive before uploading again. This approach is for developers who have received a privacy-manifest notice, not for teams looking for a general privacy-policy guide.

If you maintain CocoaPods, Swift Package, or XCFramework dependencies, use the notice path to trace the responsible component. If you handle remote Mac builds or release checks, add Archive inspection to your handoff rather than treating a clean source tree as proof of a corrected upload.

Read the notice before changing project files

An App Store Connect notice is evidence about a specific upload or component. It is not, by itself, a conclusion that App Review has rejected your app. Separate three questions before editing anything: what Apple flagged, where the flagged file or SDK sits, and whether the report describes absence or invalid content.

For ITMS-91061, read the component path as a lead to the dependency that needs investigation. Apple’s third-party SDK requirements describe the requirement for certain listed SDKs to include a privacy manifest. The notice’s path can help you locate the affected framework or package in your built app; it does not mean that the app-level manifest should stand in for that SDK’s file.

Also check the wording and status in the upload record. Apple documents build upload statuses separately from app and submission statuses. A successful upload validation is a result for that submission stage. It is not proof that App Review has approved the app.

What the notice or inspection shows	Likely issue	First check
A named embedded SDK appears with a missing-manifest report	The SDK’s manifest may be absent from its built bundle	Trace the path to the actual framework or package in the Archive
Your app bundle is identified and no manifest is present	The app manifest may be missing, excluded, or in the wrong bundle	Check target membership and the archived app bundle
A manifest exists but Apple reports it as invalid	Its structure or a value may not meet Apple’s requirements	Follow the specific validation issue in TN3181
The notice path does not match your current dependency list	The Archive may contain a different or stale dependency	Inspect the archived build inputs before changing project settings

These are diagnostic starting points, not a substitute for the exact error detail. A path that points into an embedded framework changes who needs to provide the fix; a path pointing to the app bundle makes target inclusion and packaging the immediate checks.

Compare the failure types before choosing a fix

“Missing” and “invalid” describe different failure modes. Adding a file may address absence, but it will not correct unsupported values in a file that already exists. Likewise, editing the app’s manifest will not repair an SDK’s separate bundle.

Finding	What it means	Appropriate next action	Avoid
No `PrivacyInfo.xcprivacy` in the required app bundle	The file may not exist, may not belong to the app target, or may not have been packaged	Add or include the app’s manifest, then verify the Archive	Assuming a source-folder file is automatically bundled
No manifest in a flagged third-party bundle	The dependency may lack a required SDK manifest	Identify the exact SDK and version; seek a provider update or guidance	Declaring the SDK’s practices in your app manifest
Manifest exists but has a structural error	The property list may not follow the expected format or key types	Use Apple’s invalid-manifest troubleshooting guidance	Rewriting values without checking the reported issue
Manifest parses but has an unacceptable value	The file may be syntactically valid but fail a semantic check	Compare the value with Apple’s allowed definitions	Guessing a reason, API category, or tracking domain

Apple’s TN3181 troubleshooting note helps distinguish invalid-manifest problems and provides checks for the file’s structure and values. Use it alongside Apple’s privacy manifest file reference. If the report concerns a required-reason API, consult Apple’s specific explanation of how to describe use of required-reason APIs, rather than inventing a justification.

First check: Is the manifest in the app target?

A file visible in Xcode’s project navigator is not necessarily included in the target you archive. Check the app target’s membership and build inputs, then inspect the built app bundle. Apple’s guide to adding a privacy manifest to an app or third-party SDK explains the intended placement for each kind of bundle.

Keep these states separate:

The file exists in the repository.
The file is included in the target being built.
The file appears in the correct location inside the final app bundle.

Only the last state verifies what you are about to submit. If you have multiple app targets, schemes, or build configurations, check the one that produced the reported upload. A manifest associated with a development target does not establish that the release target contains the same file.

Second check: Does the path belong to an embedded SDK?

When the notice identifies a framework or package, match that path against the dependencies actually embedded in the Archive. Dependency declarations alone are not enough: a project can resolve a different version than you expected, retain an older binary, or package a framework from another build input.

Where you find the issue	Who owns the likely correction	Evidence to collect before rebuilding
App bundle	Your app project or release configuration	Target membership, manifest content, archived app bundle
Embedded framework or XCFramework	SDK provider, or your dependency selection	Component path, resolved version, manifest in that bundle
Dependency path differs from current project state	Build or dependency-resolution inputs	Archive contents, lockfile or resolved package state, build log
File exists but validation still fails	The manifest author or the project generating it	Apple’s reported issue, property-list structure, corrected file

Apple’s third-party SDK requirements page is the reference for which listed SDKs have manifest requirements. If a dependency is responsible, identify its actual version and ask its provider for a compliant release or an explanation. If you cannot update immediately, assess whether you can remove or replace the dependency without breaking the app; do not claim its collection practices or API reasons in your app manifest to make the warning disappear.

Follow a repeatable Archive investigation

Use this sequence so that each change is tied to evidence from the affected build.

First step: Preserve the notice details

Save the full error text, code, and component path from App Store Connect. Record which build was uploaded and which scheme and configuration produced it. These details let you compare Apple’s report with the Archive you inspect; a screenshot of the headline alone may omit the path that identifies the responsible bundle.

Second step: Resolve the path to a component

Search the project’s dependency configuration and built products for the framework, XCFramework, or package named in the notice. Confirm the component’s version from the resolved dependency state or binary metadata. If the component name is unfamiliar, trace it through the dependency tree before changing app-level files.

Third step: Classify the report

Decide whether the report is about a missing file or a file that fails validation. If a manifest exists, inspect its property-list structure and the keys and values Apple flags. Use Apple’s TN3181 instructions for invalid content. Do not treat a syntax check as complete semantic validation: a file can be readable and still contain a value Apple does not accept.

Fourth step: Correct the responsible bundle

For an app-owned file, ensure the manifest is included in the release target and follows Apple’s documented placement. For an SDK-owned file, update to a provider release that includes the required manifest or contact the provider. Keep the ownership boundary intact. The app manifest describes the app; it does not replace the manifest expected inside a separate SDK bundle.

Fifth step: Build a fresh Archive

Resolve dependencies using the same release inputs you intend to submit. Create a new Archive after the correction. If you reuse an old Archive or a stale binary, you may inspect or upload the same affected dependency again, even though the source project has changed.

Sixth step: Inspect the archived products

Open the Archive’s product contents and check both the app bundle and the embedded component named in the notice. You can search an extracted Archive for the filename:

find "/path/to/YourApp.xcarchive" -name PrivacyInfo.xcprivacy -print

A search result confirms that a file with that name exists somewhere in the Archive; it does not prove that it is in the correct bundle or that its contents are valid. Compare each result’s location with Apple’s manifest placement guidance, then open the relevant file and check the content against Apple’s documentation.

Seventh step: Validate the new upload separately

Upload the corrected Archive and review the resulting status and any new messages. Compare the new notice with the saved path and error details. If the upload check passes, record that result accurately as upload validation. Keep App Review status separate; Apple’s submission status reference explains why those are different stages.

Use this release gate before submission:

The notice path has been mapped to the app bundle or a specific embedded dependency.
The fix was made in the component that owns the missing or invalid file.
The new Archive—not just the source project—contains the expected file in the documented bundle.
The manifest’s structure and relevant values have been checked against Apple’s guidance.
The upload result has been recorded separately from the review outcome.

Make the final Archive the release evidence

A common trap is to confirm that a file exists in the repository and stop there. That skips target membership, packaging, dependency resolution, and the contents of the Archive. A second trap is to edit an app manifest after an SDK-specific path was reported. That can leave the actual embedded framework unchanged while creating a misleading sense of completion.

For a reproducible release check, retain the notice, dependency state, Archive location, and inspection result together. If the Archive still contains an older SDK or the reported path remains unchanged, correct the dependency or build input before submitting again. If the manifest is present but Apple still calls it invalid, follow the specific structural or value issue rather than adding duplicate files.

Remote Mac access can help when your everyday machine cannot reproduce the release environment or when you need a clean macOS build context. It does not remove the need to verify the project’s dependencies, signing inputs, or archived products. If you are evaluating that workflow, review the available remote Mac options and check whether the listed environment fits your own build and access requirements. For teams that want to assess a particular location, the Silicon Valley Mac option is one page to inspect; confirm the current details there rather than assuming a configuration.

Frequently asked questions

Where should I start when App Store Connect reports ITMS-91061?

Start with the exact error code and the component path in the notice. The path can identify an embedded framework or SDK that needs its own privacy manifest, rather than a missing file in your app target. Then inspect the corresponding component in the final Archive. Do not copy an SDK’s privacy details into your app manifest as a substitute.

What can I do if a third-party SDK has no PrivacyInfo.xcprivacy file?

Confirm the SDK name and version from the path in the notice, then check the provider’s release notes or support channel for a compliant version. Update or replace the dependency only after verifying what will enter the Archive. If the provider has not supplied a valid manifest, report the issue to them; your app’s manifest does not declare privacy practices for a separate SDK.

How can I verify that the manifest is inside the final iOS Archive?

Inspect the archived app bundle and each relevant embedded framework, not just the project navigator or source folder. Search the extracted Archive for PrivacyInfo.xcprivacy, then check that each file sits in the bundle specified by Apple’s documentation. Rebuild after changing dependencies and repeat the inspection on the new Archive before uploading it.

Is an invalid privacy manifest the same as a missing one?

No. A missing-manifest report means the expected file was not found for the app or a required SDK. An invalid-manifest report means a file exists but fails a structural or value check, such as an incorrect property-list type or unsupported value. Identify which condition Apple reported before changing files; adding another manifest will not fix invalid content.

If your current process relies on a developer’s local Mac, it can leave release checks dependent on one machine, make dependency state harder to reproduce, and consume local storage with build artifacts. A dedicated Mac is more appropriate when you need stable, continuous workloads or physical access; a remote Mac is worth evaluating when you need a temporary or repeatable macOS environment without buying hardware for the task. First confirm the notice path and the exact Archive evidence you need, then decide whether remote access fits that verification workflow.