#532: iOS wheels, and a gate that reads the binary instead of trusting the filename

[emooreatx]

Closes #532 (wheels), and fixes a deployment-target defect found while measuring its premise.

The premise, measured first

The issue says "there is no simulator build anywhere". There is — and it ships. ios-asset.yml has been cross-compiling both slices, and ciris-server-v0.5.196-ios.tar.gz (48 MB, cosign-signed) carries them. Read off the published asset:

ios-device/_native.abi3.so       LC_VERSION_MIN_IPHONEOS 10.0
ios-simulator/_native.abi3.so    LC_BUILD_VERSION platform=iOSSimulator 14.0

file(1) prints Mach-O 64-bit arm64 dynamically linked shared library for both, byte-identically, which is probably why the simulator slice went unnoticed. If the iOS CI gate is blocked on a simulator binary, it is unblocked today — see the comment on #532.

What was genuinely missing is the wheel.

The tag has to be true

IPHONEOS_DEPLOYMENT_TARGET was never set, so the two slices took different floors — 10.0 and 14.0, from one commit in one job. Invisible in a tarball (nothing reads a minimum OS out of a tar member) and a correctness bug the moment the same binaries ship as wheels: pip installs on the strength of the tag, so the ios_13_0_arm64_iphonesimulator wheel this issue asks for would have installed on iOS 13 and failed at load. Pinned to 13.0 for both slices.

Why assembled, not maturin builded

I wrote this with maturin build --target aarch64-apple-ios first. ci.yml already says why that cannot work, in a comment directly above the job I was editing — "maturin 1.13's platform check rejects a darwin→iOS cross-compile outright". Confirmed rather than trusted; it fails before compiling anything:

💥 maturin failed
  Caused by: platform.system() in python, linux, and the rust target,
             Target { os: Ios, … }, don't match ಠ_ಠ

So tools/build_ios_wheel.py assembles the wheel from the slice cargo build already produces. The one thing it does not do is write METADATA — that would be a second spelling of the packaging rules, which stops matching the other eight wheels the first time pyproject.toml moves. It runs maturin pep517 write-dist-info (the path pip drives for prepare_metadata_for_build_wheel, no compiler needed) and takes the dist-info verbatim, rewriting only WHEEL's Tag:. Checked against the published macosx_11_0_arm64 wheel's METADATA via PEP 658: identical but for one README line the tree had legitimately moved.

The gate

Every other platform checks its own wheel by accident — a mislabelled manylinux wheel fails on the first import, on the machine that built it. iOS is the one platform where no build machine and no CI job ever loads the artifact; the device that finds out is a phone, after distribution. So tools/check_ios_wheel.py opens the wheel and reads the Mach-O load commands against the filename: sdk, arch, minimum OS, PyInit__native.

Verified three ways on a box with no macOS:

1. 11 self-test cases over hand-built Mach-O headers, so the refusals execute on every CI run (wired into ci.yml).
2. Against the real published v0.5.196 slices.
3. End-to-end — the assembler builds both wheels from those slices and the gate reads them back. RECORD hashes and sizes verified against every member; packaging.parse_wheel_filename accepts both tags.

Running the CI sequence with IPHONEOS_DEPLOYMENT_TARGET=13.0 over today's binaries reproduces the defect the pin fixes:

ios_13_0_arm64_iphoneos.whl          ✓ tag matches the binary
ios_13_0_arm64_iphonesimulator.whl   ::error:: tag claims iOS 13.0 but the
    binary's minimum is 14.0. pip reads the TAG, so this installs on iOS 13.0
    and fails at load.

Two bugs the self-test found in the gate itself, both of which would have failed correct wheels — the failure mode that gets a gate deleted:

• b"".split(b"\x00") is [b""], a truthy one-element set, so a stripped binary's empty symbol table read as "exists and lacks PyInit__native". Every stripped wheel would have been refused.
• minos < tag was treated as an error. It is safe — the binary runs everywhere the tag admits — and only minos > tag strands a device.

Scope

Release assets, not PyPI — that is what CIRISAgent's iOS CI needs, and an unproven wheel in the PyPI publish fails the upload for the whole matrix, after the tag is cut. The tarball is untouched and still built first; update_substrate_libs.py consumes it and a new packaging lane must not be able to cost us the artifact that already works. x86_64 simulator skipped (runners and simulators are both arm64); the xcframework carries the slice if it is ever needed.

Still unproven, and only CI can prove it: that IPHONEOS_DEPLOYMENT_TARGET=13.0 takes on the cargo iOS build, and that 13.0 links against Python-Apple-support's simulator dylib, which today carries 14.0. The gate makes either failure loud rather than silent.

The iOS job is kept off the PR lane deliberately — if: github.event_name != 'pull_request' || contains(…labels…, 'ci:full'), because the macOS pool is the scarce one. That is a condition, not a path filter, and ci.yml declares no types:, so adding the ci:full label does not by itself retrigger anything. Run 33721980725 is a workflow_dispatch on this branch, which satisfies the condition directly and exercises the new steps.

🤖 Generated with Claude Code

https://claude.ai/code/session_016KA4HGLvDLofp3Ejjw3FSW

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.