Cordova was listed on the list of requirements for third-party SDKs announced by Apple today.

[acn-masatadakurihara]

Cordova was listed on the list of requirements for third-party SDKs announced by Apple today.

[breautek]

Also watching https://developer.apple.com/forums/thread/742835 to see if there is a Apple response, if we do need that .framework target it will be helpful to know if SDK signatures requires a globally consistent signature if the app developer can sign their copy. It's not really clear on how exactly will XCode validate third-party SDK updates and such.

[dpogue]

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.

As for privacy manifests, Cordova itself does not collect or store any user data and does not use any of the APIs that Apple has labelled as privacy impacting. However, plugins might use those APIs, so the challenge is figuring out how to manage plugins declaring their own privacy manifests.

[breautek]

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).

[acn-masatadakurihara]

I will also share an Issue that is being addressed by Flutter, which is facing the same problem.
flutter/flutter#131940