I've received a report (beeware/Python-Apple-support#268) that the iOS App Store is now rejecting apps that include a Python framework with the following error:

ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/_hashlib.framework/_hashlib.cpython-39-iphoneos.dylib”, which includes BoringSSL / openssl_grpc, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements.

ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/_ssl.framework/_ssl.cpython-39-iphoneos.dylib”, which includes BoringSSL / openssl_grpc, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements.

The two libraries that are being flagged are libraries that link against OpenSSL, which has been flagged by Apple as an SDK that require(s) a privacy manifest and signature.

I haven't confirmed if this is also the case for the Mac App Store, but it seems highly likely that it will be.

The documentation for Privacy Manifests suggests that OpenSSL itself should be responsible for providing the privacy manifest; but it also assumes that OpenSSL will be used as an XCframework, rather than being linked and redistributed as a dynamic library. It definitely doesn't cover the iOS use case of "static linking and build-time relocation into the Frameworks folder".

OpenSSL has addressed this for macOS Framework builds; but has indicated that because they don't produce official iOS builds, they aren't going to fix the problem for iOS.

• Add an Apple privacy info file for OpenSSL openssl/openssl#24260 adds a candidate PrivacyInfo file for macOS builds
• OpenSSL iOS Privacy Manifest openssl/openssl#23262 is a discussion about the requirement for iOS
• iOS: Support Apple Privacy Manifest  openssl/openssl#23494 is a report on OpenSSL's repo about this issue on iOS

macOS isn't using OpenSSL.framework, so the implication is that this PrivacyInfo file would need to be incorporated into Python.framework. More investigation is required (including confirming whether this is actually a problem for the macOS App Store).

Based on what I've seen so far, it seems like the iOS solution will be to incorporate PrivacyInfo handling into the framework build script, and include the PrivacyInfo file next to the .so files that are being processed by the Xcode build handling. It seems likely that the macOS privacy manifest can also be used on iOS.

A very suboptimal workaround is to delete the problem files so they aren't included in a packaged app. This is only a viable workaround if you're not using the ssl or hashlib module (directly or indirectly).

CPython versions tested on:

3.13 - but it likely affects all supported CPython versions, as OpenSSL has been a dependency for a long time.

Operating systems tested on:

iOS