Skip to content

Add post-processing for .xcprivacy files and a required cryptography declaration #51

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

freakboy3742
Copy link
Member

@freakboy3742 freakboy3742 commented May 7, 2025

Refs beeware/Python-Apple-support#268.

As of April 2025, Apple has started flagging certain third-party SDKs as "privacy sensitive". This PR allows a package that provides a binary module to also provide a .xcprivacy file, which will be included in the Framework generated for the binary module.

See beeware/Python-Apple-support#285 for the change adding the required .xcprivacy files to the support package.

Submitting an app to the App Store also now requires a metadata declaration that the app doesn't use "non-exempt Encryption". This adds the required key to the Info.plist file.

Lastly, if frameworks don't provide .dSYM data, a warning is raised during archival for App Store submission. This PR adds post-processing so that if a binary module provides a .dSYM folder adjacent to the .so, it will be copied into the app bundle.

Currently submitted as a draft awaiting confirmation that this actually satisfies Apple's review requirements. It has passed initial automated reviews. An app using these changes has been accepted by the App Store.

PR Checklist:

  • All new features have been tested
  • All new features have been documented
  • I have read the CONTRIBUTING.md file
  • I will abide by the code of conduct

@johnzhou721
Copy link

Needs change in the CPython testbed as well -- also I will need to research about if Mac Catalyst is affected by this thing -- I don't have an Apple Developer account, is it okay if you build a sample app and try to submit for Mac Catalyst to the App Store to see if it passes validation stuff, after I finish with Mac Catalyst?

Also -- for the part for https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations -- what if someone actually uses non-exempt encryption in their app? Shouldn't we have a flag for this to set when building apps?

@freakboy3742
Copy link
Member Author

Needs change in the CPython testbed as well

Well... strictly, no it doesn't, because the iOS testbed is never submitted to the App Store for submission. The privacy declaration and dSYM files are only required as part of the formal submission process.

We also need to update the CPython build process to actually produce dSYM files and install .xcprivacy files - so updating testbed would be, at best, premature.

That said - the documentation in CPython should be updated to reflect this, and maybe it's worth updating testbed as a "working example" that should follow best practices. This is already on my todo list with my CPython maintainer hat on.

-- also I will need to research about if Mac Catalyst is affected by this thing -- I don't have an Apple Developer account, is it okay if you build a sample app and try to submit for Mac Catalyst to the App Store to see if it passes validation stuff, after I finish with Mac Catalyst?

Sure - but be aware that this is, at present, quite a way down my TODO list.

Also -- for the part for https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations -- what if someone actually uses non-exempt encryption in their app? Shouldn't we have a flag for this to set when building apps?

In practice, the set of people that need that option will be very small - but yes, it would make sense to have that flag exposed.

@@ -22,6 +22,8 @@
<string>????</string>
<key>CFBundleVersion</key>
<string>{{ cookiecutter.build }}</string>
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I can't suggest changes, but changing this to <{{ cookiecutter.nonexemptencryption }}/> and adding the corresponding option might work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants