Bug description:

The XCframework utility script that is used to process the dylibs in the Python standard library does two things:

1. Copies the standard library from the XCframework location in the Xcode project into the app
2. Processes all libraries in the lib/python3.x folder, and turns them into frameworks.

If you build a thin simulator framework (i.e., a single architecture), it explicitly excludes the libPython dylib from step (1). However, this isn't done for a multi-architecture simulator framework. This historically wasn't necessary, because the libPython is platform specific, and was contained in the lib-<arch> folder.

However, as a result of #141692, a multi-architecture framework now includes a lib folder that has a libpython dylib. This means step (1) now copies. By introducing a symlink in the lib folder, the util script now has two problems:

1. There's content in the lib folder that will be rejected by the App Store validation process
2. The util script breaks in such a way that it doesn't find the python3.X folder that needs to be processed in step (2).

This problem can be seen by building a full framework (i.e., python Apple ci --slow-ci) - a handful of tests will fail because .origin files for modules in the standard library aren't written. It doesn't affect the "--fast-ci" path (which is what GitHub Actions runs), as that only generates a "thin" framework.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Other

Linked PRs

• gh-146498: Ensure binary content is correctly processed in multi-arch iOS XCframeworks #146499
• [3.14] gh-146498: Ensure binary content is correctly processed in multi-arch iOS XCframeworks (GH-146499) #146502