And Android even more so.
2 Likes
We have a fully automated CI process. That’s why we use CMake. Visual Studio and Xcode projects are generated at build time by CMake. This is a pretty standard industry practice. So what’s needed is the magical incantation to tell CMake how to include an xcprivacy file in the build. Just like we do for the usual PLIST_TO_MERGE option. It’s quite possible this is easy to do and/or I am just making a small mistake. But that’s why the JUCE devs would be the best people to answer this as it’s a problem they will have to solve anyway for themselves too.
Oh, completely misread your previous comment. No idea how to do this with CMake. The PrivacyInfo.xcprivacy file is in a XcodeResources folder, in case that might help.
1 Like
We also have a fully automated CI process, but we use ProJucer.
Regardless, all my latest iOS bugs have been completely ignored, so I doubt we’ll see a fix or implementation before JUCE 8. It seems like their priorities lie elsewhere.
I haven’t tried adding the plist to ProJucer directly yet, but I think it should work.
i think you can just create Builds/iOS/PrivacyInfo.xcprivacy manually (copypasting the xml from my example above). then in projucer add the file, mark it as an xcode asset, save, and re-export.
1 Like
OK, I seem to have found a way to do this in CMake.
At least Testflight didn’t send me the dreaded email about the last submission but there is no way to get positive confirmation that it’s correct.
set(PRIVACY_INFO "path/to/PrivacyInfo.xcprivacy")
target_sources(MyPlugin_AUv3 PRIVATE "${PRIVACY_INFO}")
target_sources(MyPlugin_Standalone PRIVATE "${PRIVACY_INFO}")
get_target_property(RESOURCE_AUV3 MyPlugin_AUv3 RESOURCE)
get_target_property(RESOURCE_STANDALONE MyPlugin_Standalone RESOURCE)
list(APPEND RESOURCE_AUV3 ${PRIVACY_INFO})
list(APPEND RESOURCE_STANDALONE ${PRIVACY_INFO})
set_target_properties(MyPlugin_AUv3 PROPERTIES RESOURCE "${RESOURCE_AUV3}")
set_target_properties(MyPlugin_Standalone PROPERTIES RESOURCE "${RESOURCE_STANDALONE}")
1 Like