Publish ciris-server wheels for iOS (iphoneos + iphonesimulator)

[emooreatx]

The ask

Publish ciris-server wheels for iOS alongside the existing matrix:

• ios_13_0_arm64_iphoneos
• ios_13_0_arm64_iphonesimulator (and x86_64_iphonesimulator if the toolchain allows)

PEP 730 platform tags; the same cross-compile pipeline that already produces android_24_arm64_v8a, android_24_armeabi_v7a, android_24_x86_64, two macOS, two manylinux and win_amd64 for 0.5.196.

Why

The CIRISAgent iOS app embeds the engine with ciris_server as a native extension (ciris_server/_native.abi3.so, ~75 MB). Today that binary exists on a developer machine as an iphoneos build only, produced by hand; there is no simulator build anywhere, so the iOS half of our five-platform gate cannot run in CI. First app-side evidence from the simulator (run 33708152999) shows the embedded interpreter failing on its first imports, and once the stdlib half is fixed on our side the next failure will be exactly this module.

Android is the precedent: the three android_24_* wheels are what let the Android app ship the engine without a hand-built binary. iOS is the same shape.

Scope

Wheels only — no runtime change. If a simulator wheel is easy and a device wheel needs signing considerations, the simulator one alone unblocks CI; the device one unblocks distribution.

[emooreatx]

Wheels are in #535. But one thing in the ask is worth correcting first, because it may unblock you today rather than after a release.

The simulator build already exists and already ships

there is no simulator build anywhere, so the iOS half of our five-platform gate cannot run in CI

There is. ios-asset.yml cross-compiles both slices and ciris-server-v0.5.196-ios.tar.gz (48 MB, cosign-signed, on the v0.5.196 release) carries them. Read off the published asset, not off the workflow:

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

So if the only blocker is "we need a simulator _native.abi3.so in CI", it is one download away:

gh release download v0.5.196 --repo CIRISAI/CIRISServer -p 'ciris-server-*-ios.tar.gz'
tar xzf ciris-server-v0.5.196-ios.tar.gz          # → ios-device/, ios-simulator/

ios-simulator/_native.abi3.so is a genuine simulator binary — platform=iOSSimulator in LC_BUILD_VERSION, not a device build. Worth stating explicitly because file(1) cannot tell you: both slices print Mach-O 64-bit arm64 dynamically linked shared library, byte-identically. The difference is only in the load commands, which is probably why the simulator slice went unnoticed — and release.yml already warns when the asset is missing, so its silence was accurate.

If your side was reaching for a hand-built iphoneos binary on a developer machine, that is the thing to stop doing; this asset has been published every release.

What was actually missing, and what #535 does

The wheel. That is real and it is what #535 adds: maturin build for both targets in the existing lane, tagged ios_13_0_arm64_iphoneos / ios_13_0_arm64_iphonesimulator, attached to the release like every other asset.

Measuring the premise turned up a defect that would have bitten the exact tag you asked for. IPHONEOS_DEPLOYMENT_TARGET was never set, so the two slices took different floors — 10.0 and 14.0, from one commit in one job. Harmless in a tarball, because nothing reads a minimum OS out of a tar member. Not harmless in a wheel: pip installs on the strength of the tag, so an ios_13_0_..._iphonesimulator wheel around today's 14.0 binary installs on iOS 13 and fails at load. Pinned to 13.0, with tools/check_ios_wheel.py refusing any wheel whose binary disagrees:

::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.

That is the checker running against your requested tag over the real published slice.

Two questions for you

1. Is 13.0 the floor you want? It is what the issue asked for. If the app targets 14+, say so and I will pin 14.0 instead — the number should be yours, not inferred from an issue title.
2. Do you need these on PyPI, or are release assets enough? #532: iOS wheels, and a gate that reads the binary instead of trusting the filename #535 deliberately stops at release assets: an unproven wheel in the PyPI publish fails the upload for the whole matrix, and it fails after the tag is cut. If your build installs with pip install ciris-server rather than fetching an asset, that changes the sequencing and I will wire it once CI has produced a few good wheels.

x86_64 simulator is skipped for now — the runners are macos-14 (arm64) and so are the simulators CI drives. The xcframework carries the slice, so it is a small addition if you need Intel.

One caveat on #535: the maturin invocation and the 13.0 pin are not yet proven — there is no macOS on this box, and the 13.0 floor has to link against Python-Apple-support's simulator dylib, which currently carries 14.0. CI is the proof.

[emooreatx]

CI has now run the lane for real (run 33721980725), and it changes one of the tags you asked for.

ios_13_0_arm64_iphonesimulator is not a tag we can honestly issue

ios-device     SUCCESS   minos 10.0 → 13.0   ios_13_0_arm64_iphoneos
ios-simulator  FAILURE   minos 14.0 (unchanged, despite IPHONEOS_DEPLOYMENT_TARGET=13.0)

Setting the deployment target to 13.0 did exactly what it was meant to on the device slice — it moved off the 10.0 default it had been shipping with. It did nothing to the simulator, and that turns out not to be a configuration mistake: the arm64 iPhone simulator did not exist before iOS 14 (it arrived with Apple silicon), so the toolchain floors aarch64-apple-ios-sim at 14.0 and no deployment target lowers it.

So the two slices have genuinely different minimums because they are genuinely different platforms:

• ciris_server-<v>-cp310-abi3-ios_13_0_arm64_iphoneos.whl
• ciris_server-<v>-cp310-abi3-ios_14_0_arm64_iphonesimulator.whl

This should not affect you. An arm64 simulator only ever runs on a Mac whose simulator runtime is ≥ 14 anyway, so nothing that could have installed a 13_0 simulator wheel is excluded by a 14_0 one. If you have a reason to need 13.0 there, the only real option is an x86_64 simulator slice (Intel simulators go lower) — say the word and I will add it.

The gate refused the mistagged wheel rather than letting it out, which is the whole point of it:

::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.

build_ios_wheel.py now reads the floor out of the Mach-O instead of being told it, so each wheel's tag is true of its own binary and cannot drift from it. Re-running CI on that now.

The earlier question stands and is more useful than the 13.0 one: do you need these on PyPI, or are release assets enough? And separately — the simulator .so has been in ciris-server-v*-ios.tar.gz all along, so if that is what is blocking your CI you do not have to wait for any of this.