In this article

For ITMS-91061, start with the SDK name and path in Apple's rejection message. Obtain the vendor's appropriate SDK update, then verify its privacy manifest inside the archive you submit. Adding one generic file to your app does not necessarily repair a missing manifest in a named third-party SDK.

Apple's DTS explanation of ITMS-91061 directs app developers to the SDK provider and distinguishes the app's privacy practices from those of the SDK. This guide was checked October 8, 2026.

Classify the message before editing a manifest#

A missing SDK manifest is different from an invalid manifest or an absent required-reason API declaration. Preserve the exact error code, framework path and SDK name. If multiple SDKs are listed, make one record for each.

Do not respond to every privacy-related rejection with the same XML snippet. The file can be syntactically valid while its declarations are inaccurate or its packaging location is wrong.

Apple maintains the third-party SDK requirements and SDK list. Check the current list and the dependency actually embedded in your app, including SDKs introduced through Flutter plugins.

Trace the framework back to a dependency#

For each named framework, identify the Dart plugin, native package or binary dependency that introduced it. Record the locked version and vendor documentation for the release that includes the required manifest.

Your worksheet can be short:

text
Rejected framework path:
Owning dependency:
Version in the rejected archive:
Vendor's corrective release:
Manifest expected location:
Version and manifest in rebuilt archive:

If several plugins pull in the same native SDK, inspect the resolved native dependency rather than assuming every plugin's declared version won.

Prefer a documented vendor correction#

Upgrade the owning dependency to a compatible release containing a valid SDK manifest. Review breaking changes and build the intended production configuration. If a vendor has not supplied a correction, raise the exact SDK-path issue with that vendor; do not invent declarations about its data practices.

Apple's staff guidance says an app's manifest should describe the app's own practices, rather than absorb the SDK's practices as a substitute for the SDK manifest.

Keep the change focused. Updating all plugins at once can hide which update corrected packaging and can introduce unrelated runtime changes.

Inspect the final archive, not a source folder#

Locate the named framework in the produced archive and check that its expected privacy manifest is present. Then inspect the manifest's keys and values through Apple's current documentation. Finding a file with the correct name is only one check; it does not establish that its content accurately describes the SDK.

Retain the archive's build number and checksum with the inspection result. A stale upload may reproduce the rejection even after the repository is corrected.

Verify the next provider result#

Submit the intended rebuilt artifact through your usual authorized process and read the resulting validation message. If it lists another SDK, investigate that SDK independently. Do not classify the entire application as compliant merely because the first error disappeared.

For generated patches, use our AI code review checklist, especially the checks for unsupported assumptions and unexplained configuration changes. Privacy declarations should reflect actual behavior; a tool's confident suggestion is not evidence about what a third-party binary collects.