breautek commented on issue #1391: URL: https://github.com/apache/cordova-ios/issues/1391#issuecomment-1847410109
> Cordova itself is not distributed as a .framework or .xcframework file, so as far as I'm aware no SDK signing is necessary. When you create a Cordova app, the CordovaLib code is included as part of the app project. I'm not sure if this is entirely true. Cordova is distributed as source, but it is it's own independent project. We just don't pre-compile it. But the `CordovaLib` project has 2 targets, a static `CordovaLib` target, and a `Cordova` framework target. I'm not sure if the Cordova framework target is actually used because on the App project, it looks like it links against the `CordovaLib` static library. In my own project built by the Cordova CLI, there is no sign of cordova.framework present, i think the target just exists for whatever (probably legacy) reasons. Perhaps some people have their XCode projects modified to use the unsigned framework instead of the static library (or maybe there is a cordova flag that controls this too?). I'm not sure if there is any benefit of having a .framework target vs just the static library target, so maybe one can be removed? If any project is actually using the Cordova.framework target, that target will need to be signed. But I'm not sure if it can be signed by the app developer of it needs to be signed by Apache for a globally consistent signature. > Now with signatures for SDKs, when you adopt a new version of a third-party SDK in your app, Xcode will validate that it was signed by the same developer, improving the integrity of your software supply chain. Like I'm not 100% sure what this means or how they are really doing the validating. As for the privacy manifest, most plugins don't have their own XCode project and instead their sources are directly added to the app project. So the app needs a xcprivacy file. Good news is, we can probably have an intermediate JSON structure that is used to help de-dupe or generate the xcprivacy file and we can probably incorporate some plugin.xml directives that helps plugins control it. A sample xcprivacy that I have for a geolocation project will look something like: ``` <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> <plist version="1.0"> <dict> <key>NSPrivacyCollectedDataTypes</key> <array> <dict> <key>NSPrivacyCollectedDataType</key> <string>NSPrivacyCollectedDataTypePreciseLocation</string> <key>NSPrivacyCollectedDataTypeLinked</key> <false/> <key>NSPrivacyCollectedDataTypeTracking</key> <false/> <key>NSPrivacyCollectedDataTypePurposes</key> <array> <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string> </array> </dict> <dict> <key>NSPrivacyCollectedDataType</key> <string>NSPrivacyCollectedDataTypeCoarseLocation</string> <key>NSPrivacyCollectedDataTypeLinked</key> <false/> <key>NSPrivacyCollectedDataTypeTracking</key> <false/> <key>NSPrivacyCollectedDataTypePurposes</key> <array> <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string> </array> </dict> </array> <key>NSPrivacyTracking</key> <false/> </dict> </plist> ``` You don't put any actual human facing text in it. It's all constants that describe what privacy-sensitive features you're using, and constants that explain the reason or purpose for using. This was always required when distributing apps but it was done through the App Connect web portal, so this newer xcprivacy file allows more programmatic usage as well as putting the responsibility for SDK authors to provide their own privacy manifests (rather than the app developer trying to guess what a SDK may or may not do). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
