Added Apple privacy manifests for iOS and macOS

[britzl]

This change adds an Apple Privacy Manifest (PrivacyInfo.xcprivacy) to builtins for both iOS and macOS. The privacy manifest will also be added as a game.project setting for both iOS and macOS. If the project also contains native extensions any privacy manifests used by the extensions or any extension dependencies these will be merged with the project manifest. The merged (or original manifest) will be included in the bundled app.

Including a privacy manifest will be required by Apple when uploading to App Store Connect:

"If you upload an app to App Store Connect that uses required reason API without describing the reason in its privacy manifest file, Apple sends you an email reminding you to add the reason to the app’s privacy manifest. Starting May 1, 2024, apps that don’t describe their use of required reason API in their privacy manifest file aren’t accepted by App Store Connect."

Source: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api?language=objc

Fixes #8378

PR checklist

• Code
  • Add engine and/or editor unit tests.
  • New and changed code follows the overall code style of existing code
  • Add comments where needed
• Documentation
  • Make sure that API documentation is updated in code comments
  • Make sure that manuals are updated (in github.com/defold/doc)
• Prepare pull request and affected issue for automatic release notes generator
  • Pull request - Write a message that explains what this pull request does. What was the problem? How was it solved? What are the changes to APIs or the new APIs introduced? This message will be used in the generated release notes. Make sure it is well written and understandable for a user of Defold.
  • Pull request - Write a pull request title that in a sentence summarises what the pull request does. Do not include "Issue-1234 ..." in the title. This text will be used in the generated release notes.
  • Pull request - Link the pull request to the issue(s) it is closing. Use on of the approved closing keywords.
  • Affected issue - Assign the issue to a project. Do not assign the pull request to a project if there is an issue which the pull request closes.
  • Affected issue - Assign the "breaking change" label to the issue if introducing a breaking change.
  • Affected issue - Assign the "skip release notes" is the issue should not be included in the generated release notes.

---

Example of a well written PR description:

1. Start with the user facing changes. This will end up in the release notes.
2. Add one of the GitHub approved closing keywords
3. Optionally also add the technical changes made. This is information that might help the reviewer. It will not show up in the release notes. Technical changes are identified by a line starting with one of these:
   1. ### Technical changes
   2. Technical changes:
   3. Technical notes:

There was a anomaly in the carbon chroniton propeller, introduced in version 8.10.2. This fix will make sure to reset the phaser collector on application startup.

Fixes #1234

### Technical changes
* Pay special attention to line 23 of phaser_collector.clj as it contains some interesting optimizations
* The propeller code was not taking into account a negative phase.

[AGulev]

Does this API end up in release build? I thought Remotery.c is debug only

[britzl]

Yes, by default at least. But I suppose you could make a release with Remotery available right? The described reason is also not very restrictive:

35F9.1
Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers.

Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.

[JCash]

"But I suppose you could make a release with Remotery available right"

But then I would also assume that the developer would add a custom privacy manifest?
But if it doesn't matter, then sure.

[britzl]

Yes, the developer can copy the file and modify it. Or we should include one file for release and one for debug builds? Or remove this value from the default?

I honestly don't think it matters much and we can change it later.

[AGulev]

It would be nice if we be able to use info from app manifest to keep or remove blocks from there. Something similar we do based on info from game.project using mustache tamplates.

something like this in PrivacyInfo.xcprivacy

...
{{^appmanifest_libs.profilerext_null}}
<dict>
         <key>NSPrivacyAccessedAPIType</key>
         <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
         <key>NSPrivacyAccessedAPITypeReasons</key>
         <array>
                 <string>35F9.1</string>
         </array>
 </dict>
{{/appmanifest_libs.profilerext_null}}
...

But maybe it's something we should think about in a separate iteration

[AGulev]

👍

[AGulev]

It would be nice if we be able to use info from app manifest to keep or remove blocks from there. Something similar we do based on info from game.project using mustache tamplates.

something like this in PrivacyInfo.xcprivacy

...
{{^appmanifest_libs.profilerext_null}}
<dict>
         <key>NSPrivacyAccessedAPIType</key>
         <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
         <key>NSPrivacyAccessedAPITypeReasons</key>
         <array>
                 <string>35F9.1</string>
         </array>
 </dict>
{{/appmanifest_libs.profilerext_null}}
...

But maybe it's something we should think about in a separate iteration

[AGulev]

I didn't check the full list myself, I hope we didn't miss anything, esp. for things in libs (when we use already compiled libraries from packages, not source code)