Add support for building ARM64 iOS wheels on CI

[ambv]

This will greatly enable the iOS platform in terms of support for other packages that depend on cffi. See PEP 730 for details about the iOS platform support in Python.

This was a little tricky to get right:

• every iOS build is a cross build so depending on pkg-config or homebrew is invalid;
• for iOS builds, the setup.py in this repository can't be called directly, but rather through cibuildwheel, which effectively runs python -m build but with a special python that pretends it's running on sys.platform == "ios" with an almost empty $PATH to avoid pulling in ABI-incompatible dependencies;
• this platform requires dedicated builds of libffi which additionally preferably are statically linked into our resulting wheel's .dylib;
• the location of the unzipped sdist is different from what cibuildwheel docs suggest you should put in CIBW_TEST_SOURCES.

Now, the current status is such that we're running the src/test_c.py tests with some expected skips (callbacks = executable memory, disallowed on iOS) but also two unexpected failures. I marked one with xfail, the other is a skip because it crashed the test runner with Python 3.13. Worth investigating after the fact once the CI is set up.

The tests from testing/ are not enabled for iOS since they depend on ffi.verify(), which attempts in-place compilation, impossible on iOS.

[ambv]

Everything built fine on the branch:
https://github.com/ambv/cffi/actions/runs/16500758807

[ambv]

Newest run with macOS 15 passed as well: https://github.com/ambv/cffi/actions/runs/16519616901.

[ambv]

Everything's still green after #178: https://github.com/ambv/cffi/actions/runs/16579222190

[ambv]

While it looks a little weird to download binaries from beeware, cibuildwheel internally actually does the same for the "iOS support" python interpreter used to run python -m build with.

[ambv]

The CI failures here are intermittent GitHub.com HTTPS availability issues. They'll pass if you kick them.

[ambv]

Looks like GitHub's got an outage:

[mattip]

Will try again in a few hours

[mattip]

the last commit does not seem to work

[ambv]

Yeah, that added -I broke it. I'll just revert it.

[ambv]

@mattip do you need me to do anything here?

[mattip]

LGTM. @nitzmahone would you like to take a look?

[webknjaz]

It would make sense to plug this into the cibuildwheel config so that it's usable outside the CI and isn't coupled with it.

[ambv]

@webknjaz every little change I make here requires somebody to manually approve the CI to run for me. Let's ignore the nits for now.

[nitzmahone]

@ambv do you happen to know offhand if the libffi build you're embedding (and/or iOS in general) needs the same trampoline dylib stub hacks that MacOS aarch64 does? It's been several years since I dug into that, but IIRC it was at least required to enable marking pages executable for dynamic codegen without using a highly-restricted entitlement. Most vanilla libffi builds were just delegating that part to the Apple-built stub (which has the necessary entitlement), which is of course very fragile for statically-linked stuff should it ever change.

I also see a bunch of the tests around dynamic codegen have been disabled for iOS anyway, so maybe it's all moot, but the details escape me if libffi needed that stub dylib for anything else.

[ambv]

@nitzmahone asks:

do you happen to know offhand if the libffi build you're embedding (and/or iOS in general) needs the same trampoline dylib stub hacks that MacOS aarch64 does? It's been several years since I dug into that, but IIRC it was at least required to enable marking pages executable for dynamic codegen without using a highly-restricted entitlement. Most vanilla libffi builds were just delegating that part to the Apple-built stub (which has the necessary entitlement), which is of course very fragile for statically-linked stuff should it ever change.

The bad news is that I have no idea about trampoline dylib stub hacks. The "good" news is that on iOS any form of marking pages for execution is disallowed by the kernel (no userland JITs supported due to security concerns), so it seems like at the moment it's not a problem either way.

[mattip]

CI is quickly failing

[ambv]

@mattip, reverted the breaking change.