Hello

Use a pre-packaging script to copy the final PrivacyInfo.xcprivacy file in your app bundle's next to the final Info.plist. Something like this:

% embed-privacy-info.bat
@echo off

rem // copy the PrivacyInfo.xcprivacy file that the App Store expects to find for your app
copy /y /b "C:\path\to\my\apps\PrivacyInfo.xcprivacy" "%TARGET_BUILD_DIR%\%NAME%.app"

rem // if third-party frameworks have a PrivacyInfo.xcprivacy file too, copy them in the relevant places
copy /y /b "C:\path\to\framework1\PrivacyInfo.xcprivacy" "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\framework1.framework"
 copy /y /b "C:\path\to\framework2\PrivacyInfo.xcprivacy" "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\framework2.framework"
rem // etc...
%

:: @Pierre-Marie Baty added on 03 Mar ’25 · 15:24

*edit* more info about pre-packaging scripts can be found in the builder's documentation (readme.html).

You need to copy the file called "PrivacyInfo.xcprivacy" for your app (if your code use APIs from the iOS SDK that imply you need one) next to your app's Info.plist in the app bundle.

And similarly, you need to copy the file called "PrivacyInfo.xcprivacy" of each framework that requires one next to that framework's Info.plist.

The app bundle is the directory ending in ".app" that the builder constructs, and which is then zipped into an .ipa file. Before it is zipped, it can be found (for a Unity project) in build\Release-iphoneos\iPhone-target\yourAppName.app.

Just write a batch script that does this. If you're not comfortable with batch scripts, write a powershell one.

I can provide more details on whatever point that needs it (just ask), but I cannot write the keys-in-hand script for everyone of you : every project has its own particularities, each one of you has it under a different path, each of you has a different set of .xcprivacy files, located in different places, and I'd feel I'd be doing everybody's homework here.

@YoNeyers: this script can work, but note here that you're copying the same PrivacyInfo.xcprivacy in two places. I think one should be enough, so if you have only one .xcprivacy file, it might be best to copy it just once, in the app bundle.

Also note that when the pre-packaging script is run, there are already a few environment variables set by the master build script that you can reuse, that already point to common build locations. To obtain the list of those variables, put "set & pause" somewhere in your script. The variables will be displayed the next time you build your project and it'll wait for you to press a key. Copy/paste them somewhere for reference, and remove "set & pause". Then you can rewrite your script into a reusable one using these variables, that will automatically adjust the paths to your specific project.

Like I said. Use the %TARGET_BUILD_DIR% and %NAME% environment variables like this: %TARGET_BUILD_DIR%\%NAME%.app

Hello Ruslan,

If your project has multiple PrivacyInfo.xcprivacy files, supplied by different pods, try in this order:

1. Merge all these files into one using a text editor (they're basically XML files, so just copy the key/values to form one single XML file, merging the keys that have the same name), then use only the resulting PrivacyInfo.xcprivacy file as the sole privacy info file source for your app, and copy it in place using the pre-packaging script technique described above.

2. If the above doesn't work, try copying each .xcprivacy file (from each pod that has one) to its relevant compiled .framework folder (for example, C:\Users\LocalComp\Desktop\build\Pods\GoogleUtilities\GoogleUtilities\Privacy\PrivacyInfo.xcprivacy would go to %TARGET_BUILD_DIR%\%NAME%.app\Frameworks\GoogleUtilities.framework\PrivacyInfo.xcprivacy -- this is just an example) using multiple copy statements, one for each file, using the same technique as above.

I'm not sure how Apple prefers this information to be presented in the final app, either one single .xcprivacy file for the whole app, or one per Mach-O executable. I read there should be one for each executable bundle, but while the compiled .app directory itself is a bundle, each dynamic framework in a .framework directory inside it is *also* a bundle, so...

Hello @Ruslan

You said: "I also tried merging everything into a single file as you suggested earlier and adding it to the final build, but it still didn't work."

My understanding has progressed on this and I think that's the way to go. So maybe there was a formatting problem in the XML file you created. Could you show me the result of this merge ?

It is possible that the two empty lines at the beginning of the NSPrivacyAccessedAPITypes array make the Apple parser choke. Try removing them. Also, it might be that Apple expects this property list to be converted to binary format. Use the "plconvert" command-line utility (from the Toolchain directory) to do that. Let me know, I think we're close to success.

There might be a misunderstanding on terminology here. "Signing" means "code signing", it is the process by which a bundle is sealed by a code signature, embedding a signer certificate, that covers both the code and the resources. This is done at the last step of the build process, by the code signer, after all pre-packaging scripts have been executed, and before the app is packaged in an .ipa bundle. So, if your scripts change anything in the app's structure, the code signer will sign the app in the very state that your scripts left it, and the code signature will be objectively valid - no matter whether the data that was signed was correct. You don't need to sign it again after this point, unless you intend to unpack an .ipa, make changes to it, and pack it again. Also, the code signing process is recursive, which means every signable framework and bundle in your app that can be signed, in addition to the app itself, will be signed, as well as any framework and bundle on which these frameworks depend.

The 2 lines you posted don't "sign" anything. They just copy a file from one location to another.

Property lists in either XML or binary format are read and understood in a strictly equivalent way by the toolchain's utilities. My plist library understands 3 formats: XML, binary and NeXTStep/ASCII (the latter for .pbxproj files, which are also property lists, although this format comes straight from the 1990s and is no longer documented anywhere AFAIK). Converting your .plist files from one format to another is indifferent to the code signer.

I hope it begins to be more clear for you.

Forget what I said before. We were on the wrong track.

By reading this article: https://developer.apple.com/documentation/Technotes/tn3181-debugging-invalid-privacy-manifest?language=objc on the Apple website, I am under the impression that an iOS app may include *several* privacy manifests, i.e. one per SDK:

“If you upload an app to App Store Connect that contains invalid privacy manifest files, you’ll receive an email that includes the name and path of the invalid files in your app bundle.”

Note the plural.
This contradicts the impression I had in post #18.

The conclusion is that you don't need to merge all the privacy manifest files in a single one, just take each of them as they are supplied by each SDK provider, and copy them in the relevant framework in the final app. And there's no need to convert it to binary format either, a simple copy is sufficient.

Use this script and make the necessary changes:

% pre-packaging-script.cmd
@echo off
setlocal enabledelayedexpansion

rem // in case your own code makes use of Apple APIs that require a PrivacyInfo file,
rem // then uncomment these lines and change the path to your own PrivacyInfo.xcprivacy file
rem set PRIVACY_FILE="C:\Path\To\Your\Own\PrivacyInfo.xcprivacy"
rem copy /b /y "%PRIVACY_FILE%" "%TARGET_BUILD_DIR%\%NAME%.app"

rem // now process the PrivacyInfo files supplied by Google
rem // this is based on the screenshot you published in post #15.
if exist "Pods\PromisesObjC\Sources\FBLPromises\Resources\PrivacyInfo.xcprivacy" (
   if exist "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\FBLPromises.framework\" (
      copy /b /y "Pods\PromisesObjC\Sources\FBLPromises\Resources\PrivacyInfo.xcprivacy" "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\FBLPromises.framework\"
   )
)
if exist "Pods\GoogleUtilities\GoogleUtilities\Privacy\PrivacyInfo.xcprivacy" (
   if exist "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\GoogleUtilities.framework\" (
      copy /b /y "Pods\GoogleUtilities\GoogleUtilities\Privacy\PrivacyInfo.xcprivacy" "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\GoogleUtilities.framework\"
   )
)
if exist "Pods\nanopb\spm_resources\PrivacyInfo.xcprivacy" (
   if exist "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\nanopb.framework\" (
      copy /b /y "Pods\nanopb\spm_resources\PrivacyInfo.xcprivacy" "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\nanopb.framework\"
   )
)
if exist "Pods\GoogleUserMessagingPlatform\Frameworks\Release\UserMessagingPlatform.xcframework\ios-arm64\UserMessagingPlatform.framework\PrivacyInfo.xcprivacy" (
   if exist "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\UserMessagingPlatform.framework\" (
      copy /b /y "Pods\GoogleUserMessagingPlatform\Frameworks\Release\UserMessagingPlatform.xcframework\ios-arm64\UserMessagingPlatform.framework\PrivacyInfo.xcprivacy" "%TARGET_BUILD_DIR%\%NAME%.app\Frameworks\UserMessagingPlatform.framework\"
   )
)
%

I haven't tested this script (and I cannot, since it's specific to your situation), but it should be clear enough for you to understand what's going on and how to fix it if necessary.