pypa
iOS builds do not protect against linking in dynamic libraries.
Description
iOS has very stringent requirements for dynamic linking. It does not allow simple .dylibs; all dynamically loaded content must be packaged as Frameworks.
As a result, binary modules build by cibuildwheel should statically link all third-party code.
However, cibuildwheel doesn't currently protect against this.
Pillow 11.3.0 recently added iOS wheels; but those wheels inadvertently included a dynamically linked libjpeg.6.2.dylib - something that wasn't detected until the wheel was published (as the dynamic library existed in the linked location during CI testing). See python-pillow/Pillow#9079 for details.
cibuildwheel should add a dynamic linking audit to the iOS backend.
This is strictly an enhancement, as cibuildwheel is currently working "as intended"; but the fact that it's possible to produce invalid iOS wheels with a fairly trivial misconfiguration makes this a fairly important enhancement.
Build log
https://github.com/beeware/Python-support-testbed/actions/runs/15817251844
CI config
No response
For the benefit of future searches: https://github.com/python-pillow/Pillow/issues/9079 referred to this as an "auditwheel analog".
It may eventually become necessary to include dynamic libraries in an iOS wheel, especially in packages where multiple Python modules link against the same library. Aside from the extra size from duplicating the library, there may also be correctness and stability issues caused by each Python module containing its own separate copy of the library's global variables.
Could we do the same thing with dynamic libraries as we already do with Python modules: requiring the app build tool (e.g. Briefcase) to wrap them into frameworks, and adapting the Python module loader to find them at runtime?
I agree it's definitely desirable; and may eventually become necessary.
I suspect you're right that the existing dynamic library approach used by macOS etc might work (or can be made to work with appropriate modifications). Trying to make existing macOS auditwheel tooling work for iOS may well be a better use of time than writing a new audit wheel that works for static-only iOS wheels.