Apple's TN3181 troubleshooting note says an App Store Connect notice can identify an invalid manifest by file name and archive path. Start with that path: determine whether the file belongs to your app target, a Swift Package, or a third-party SDK, then fix it at its source and create a fresh archive. Don’t delete or overwrite a manifest before you know who owns it.
This guide is for you if you received an invalid privacy manifest notice and need to locate the named file. It also covers teams updating SDKs and developers who need a repeatable Xcode Archive check before submission.
The key decision: the file path points to the source of the fix. The fact that the app’s submission was rejected does not mean the app’s main manifest is necessarily the problem.
Start with the path in the rejection notice
An invalid manifest is a file-level problem to investigate, not a reason to rewrite your App Store Connect privacy labels. A privacy manifest describes specified privacy practices and API use. App privacy details in App Store Connect are a separate part of submission. Keep those tasks separate while you diagnose the rejection.
How do you find the specific file named in the notice? Read the notification’s file name and archive path, then match that path to the corresponding item in the archived app. Apple’s troubleshooting guide uses the path and the manifest’s reported issue to guide diagnosis. Don’t assume that a file with the same name in your source tree is the one Apple checked.
| Clue in the notice or archive | Likely owner | First place to investigate |
|---|---|---|
| Path under the main app bundle, with no dependency or framework context | App target | Target membership, build resources, and the archived app’s manifest |
| Path associated with a package dependency | Swift Package | The package target’s resource declaration and the manifest in the archive |
| Path inside a framework or SDK bundle | Third-party SDK | The SDK version, its bundled manifest, and the SDK publisher’s release material |
Use the table to choose your first investigation, not to make a final diagnosis. Confirm ownership from the archive and project configuration. Apple’s manifest layout documentation explains where manifests belong in app and bundle structures.
What if the notice names a file but the same file isn’t obvious in your project? Inspect the archived product rather than relying on a source-tree search. Dependencies can contribute their own manifests, and the archive may contain a different build or dependency version than the one open in your editor.
Check whether your app target includes its manifest
For an app-owned manifest, verify both its contents and whether the target that produces the submitted app actually includes it. A file sitting beside a project file does not prove that it is part of the built product. Check target membership and the build resource configuration in Xcode, then inspect the result in the archive.
Apple’s instructions for adding a privacy manifest distinguish adding a manifest to an app from adding one to a third-party SDK. The manifest layout reference gives you the expected location in the bundle. Compare those requirements with the path in your submission notice.
| Check | What to inspect | What a mismatch suggests |
|---|---|---|
| Target membership | Whether the manifest belongs to the app target being archived | The file may exist in the repository but not be built into the submitted app |
| Build resources | Whether the target copies the manifest into the product | Project configuration may omit the resource |
| Archive contents | Whether the archived app contains the expected manifest at the expected location | The archive may not reflect the source file or target you checked |
Don’t combine every declaration into the main app manifest just to make a rejection go away. An app’s declarations and a dependency’s manifest have different ownership. If the app itself uses a required reason API, document that usage in the app’s manifest according to Apple’s current rules. If an SDK supplies a manifest, check that bundle separately.
When a Swift Package manifest is missing from the archive
A Swift Package can contain a PrivacyInfo.xcprivacy file in its source directory without bundling it into the built product. The package target must declare the file as a resource where required; directory presence alone is not evidence that the package will include it.
Why can a package’s manifest be absent even though it is in the repository? Check the package manifest and the resource configuration for the target that builds the dependency. Apple’s Swift Package resource documentation explains how resources are declared for package targets. Then inspect the resulting archive to confirm that the manifest is present in the built bundle.
| Package check | Evidence to compare | Next action |
|---|---|---|
| Package target | The target that contributes code to the app | Confirm the manifest is declared as a resource for the relevant target |
| Resource declaration | The package’s resource configuration | Correct the package configuration rather than relying on the file’s location |
| Built dependency | The package’s output in the archive | Confirm that the manifest travelled into the built product |
If the package is maintained by your team, fix its resource declaration at the source and rebuild the app. If it comes from an external dependency, check the package’s published materials and version history before editing copied files in your project. A local workaround can disappear on the next dependency update.
Treat a framework or SDK path as an SDK issue first
If the notice points into a framework, SDK, or XCFramework bundle, identify which dependency produced that path. Match the framework name to your dependency configuration and record the resolved SDK version. Then compare the archived manifest with the version supplied by the SDK publisher.
Should you change your app or contact the SDK developer? First determine whether the invalid file belongs to the SDK. If it does, check for a release with a corrected manifest and follow Apple’s guidance for repairing an invalid third-party manifest. Contact the SDK publisher if you cannot confirm a valid correction or if the distributed file still fails validation. Don’t silently replace the SDK’s declaration with an app-level declaration: that can leave the offending file in the archive.
| Evidence | How it helps | Appropriate response |
|---|---|---|
| Archive path inside an SDK bundle | Identifies the bundle containing the reported file | Trace it to the dependency and its resolved version |
| Dependency lock or resolution record | Shows which SDK build produced the archive | Reproduce with the same dependency version before changing it |
| SDK publisher’s release notes or supplied manifest | Shows whether the publisher has corrected the file | Update or ask the publisher for a verified fix |
Apple’s guidance for adding manifests to apps and third-party SDKs provides the relevant ownership distinction. The publisher’s own release material is useful for confirming which SDK release contains the manifest you expect.
Don’t patch the archived SDK bundle as your normal fix. Changing files inside a signed framework can invalidate its signature. Resolve the issue through a corrected SDK release or a documented Apple-compatible process, then rebuild and verify the archive. Apple’s code-signing technical note explains why changing signed code affects signature validity.
Check the manifest’s keys and values against current Apple rules
A manifest can be present in the correct location and still be invalid. Compare its structure, keys, and values with Apple’s current documentation and the exact error reported by validation. Don’t add a reason or declaration simply because a key looks plausible.
Keep two kinds of declaration distinct:
- Required reason API use: the manifest identifies relevant API use and an allowed reason. Check Apple’s required reason API documentation for the current API and reason combinations.
- Data use: the manifest describes applicable data collection and related purposes. Use Apple’s data-use documentation to check the structure and meaning of those declarations.
Can you add a reason that seems likely and test whether submission passes? Don’t guess. Tie every required reason declaration to the API use in your app or dependency, and select only a reason Apple currently permits for that API. For data declarations, verify that the entry describes the relevant app or SDK behavior; a reason for API use is not a substitute for a data-use declaration.
When validation reports a key, value, or structural issue, compare the specific item in the manifest with the matching Apple documentation. Keep the exact rejected file unchanged until you have captured the error and determined its owner. That gives you a clear before-and-after record and avoids confusing a content error with a packaging error.
Rebuild and verify the Xcode Archive you plan to submit
A source edit is not proof that the submitted package is fixed. The corrected file must reach a newly created archive, and the archive you validate must be the one you intend to submit. Apple’s Xcode distribution documentation describes the archive and distribution workflow.
Follow this sequence:
- [ ] Save the rejection notice and copy the reported file name and archive path.
- [ ] Locate that path in the relevant archive and identify whether it belongs to the app, a package, or an SDK.
- [ ] Check the owning target or dependency configuration and compare the manifest with Apple’s current documentation.
- [ ] Make the fix at the source: adjust the app target, correct the package resource declaration, or update and verify the SDK.
- [ ] Build a new archive after the change. Don’t reuse an older archive just because it appears in Organizer.
- [ ] Inspect the new archive and confirm that the corrected manifest is present at the expected path.
- [ ] Run Xcode’s submission validation for that archive, review any remaining notices, and submit only after the validation result matches the archive you inspected.
How do you verify the file that will actually be submitted? In Xcode Organizer, select the new archive and use the archive’s distribution workflow to inspect and validate it. Compare the resulting product with the path from the rejection notice. If the path still points to an SDK bundle, the app-level fix did not remove or correct that SDK manifest.
Avoid editing or removing files directly inside an archive as a shortcut. Any change to signed content can affect signature validity. If an exceptional repair requires altering bundled content, follow Apple’s signing guidance and ensure that the final product is signed and validated as required. For ordinary fixes, rebuilding from corrected source is easier to audit and less likely to leave you with a package different from the one Xcode validated.
Keep a short repair record for your team: the rejection path, the owning target or dependency, the change made, the dependency version if relevant, the new archive selected, and the validation result. That record makes it easier to tell whether a later rejection is the same issue or a new file in a different bundle.
If you do this work on a remote Mac, the diagnosis does not change: inspect the archive produced by the project, then validate that same archive in Xcode. Make sure your team can access the relevant source, dependency records, and signing credentials under its own security practices. The Mac is a build environment, not a substitute for keeping control of the project and its signing assets.
For a release that needs a Mac only for archive creation and submission checks, compare a remote Mac workflow with your current setup before buying hardware. Remote access can avoid a dedicated local machine and let you work in macOS when needed; it also depends on network access, requires careful credential handling, and adds recurring rental cost. If you build and sign continuously or need direct access to physical devices, a dedicated Mac may fit better. You can review Mac environment options and the OsxNode access documentation before deciding whether a temporary rental suits your release workflow.
The reliable fix is the one that follows the rejected path back to its owner, corrects the source, and passes validation in a fresh archive. If you lack a usable Mac for that release check, renting one through OsxNode is an option to consider; if you already have a stable Mac setup, keep using it and apply the same archive-level verification.
Validate Your App Archive on a Dedicated Remote Mac
Rent an OsxNode Mac mini M4 by the day and test your build without buying a Mac.
Rent a Mac by the day