The published binary fallback on main cannot match HEAD bindings

[TarikGul]

Package.swift on main falls back to a published xcframework when no local one
is staged. That fallback cannot hold the pairing the generated code enforces.

The binary comes from a release commit. The Swift bindings are gitignored and
generated from whatever commit you are on. UniFFI checks that pairing at
initialization, so unless the two come from the same commit the pairing is only
correct by luck.

Measured between main and the newest published asset, 0.13.1:

	main	tag 0.13.1
bindings_contract_version	30	30
checksum constants	62	62
..._hostcallbacks_auth_state_changed()	35488	50346

One value differs. That is enough, because the check is a single lazy global and
any mismatch returns apiChecksumMismatch for the whole library:

private let initializationResult: InitializationResult = {
    ...
    if (uniffi_truapi_server_checksum_method_hostcallbacks_auth_state_changed() != 35488) {
        return InitializationResult.apiChecksumMismatch
    }

So it is not one degraded callback with the rest working. Every use of
TrUAPIHost fails to initialize.

Who this reaches

Almost nobody, which is why it has gone unnoticed.

	resolves the fallback
CI	no, TRUAPI_USE_LOCAL_BINARY: "1"
the in-tree iOS host	no, in-tree core and a staged binary since #679
a consumer pinning a semver tag	no, it reads that tag's own manifest
a clean clone with bindings generated but no xcframework	yes

swift package resolve also downloads the 74 MB asset before the build fails on
missing FFI headers, so a clean clone pays for it and cannot use it.

What is not wrong

The consumer tags are correct and should stay as they are. Each plain semver tag
carries generated sources and a manifest pointing at its own asset:

tag	publishedBinaryURL	FFI headers on the tag
0.7.0	0.7.0	present
0.12.0	0.12.0	present
0.13.1	0.13.1	present

Verified by resolving exact: "0.13.1" from a throwaway consumer package: it
fetched the 0.13.1 asset and the checksum validated. Bindings and binary on a
tag come from one commit, which is exactly why tags work. That property is the
reason to keep the fallback on tags and reconsider it only on main.

The bookkeeping problem underneath

release-ios.yml opens a pull request after each release to move main onto the
new asset. Those do not land:

• build(ios): publish host XCFramework 0.13.1 #582 sets main to 0.13.1, open since 2026-09-02
• build(ios): publish host XCFramework 0.12.0 #556 sets main to 0.12.0, open since 2026-08-31

#582 has no CI Status because a bot-authored pull request needs its workflows
approved, and the explicit workflow_dispatch run the release workflow triggers
does not attach as a pull request check. So main sits on 0.7.0.

Merging #582 is accurate bookkeeping and changes no behaviour: the asset and
checksum verify, and the one case that reads the fallback fails at init either
way. #556 is superseded and would walk main backwards if it merged later.

Decisions

• Should main keep a published fallback at all, given it cannot be correct
  between releases?
• If not, what does a clean clone get instead, given the build already
  requires generated bindings?
• Close build(ios): publish host XCFramework 0.12.0 #556 as superseded, and decide whether to merge or close build(ios): publish host XCFramework 0.13.1 #582
• Should CI exercise the published fallback at all, since
  TRUAPI_USE_LOCAL_BINARY: "1" means a wrong URL or checksum is invisible
  to every current job?

[TarikGul]

Direction agreed on #725: drop publishedBinaryURL and have the package rely on the core in
this tree, rather than keep bumping a URL that keeps going stale.

Two things that make it viable now:

• .github/consumers.json lists no consumers for @parity/ios-host.
• The iOS host resolves the core in-tree as of Point the iOS host at the in-tree core #679, so the app that was the real SwiftPM
  consumer no longer resolves a tag.

One constraint to design around. The release tags carry zero files under
ios/truapi-host/Binaries/, so the xcframework only ever exists as a release asset. Removing
the URL therefore means any consumer builds it from Rust themselves. For a host in this tree
that is make ios-bootstrap; for anything outside it is a Rust toolchain requirement, which
is the cost the published asset exists to avoid.

So the change is not just deleting two constants. It also makes part of release-ios.yml
moot, since uploading an asset nothing references has no purpose. That is why it wants doing
here rather than inside a manifest pull request.

In the meantime #725 makes the in-tree host prefer a staged local xcframework when present,
which avoids the skew without changing what remote consumers get. That is a workaround; this
issue is the fix.

[TarikGul]

Correcting the original framing, which was wrong. The body above is rewritten.

The first version claimed every published tag's manifest pointed at the 0.7.0
asset. That came from reading the @parity/ios-host@<version> release tags. Those
are not what a consumer resolves. tag-release.sh pushes a plain semver tag as
the consumer artifact, and each of those correctly points at its own asset and
carries the generated sources. So there is no version skew on any tag, and the
runtime mismatch described for consumers does not exist.

What replaced it is narrower but harder to fix by bumping a URL. The fallback on
main pairs a binary from a release commit with bindings generated from HEAD, and
a single differing checksum fails the whole library at init. Bumping main to the
newest asset still leaves one mismatch today, so it cannot be fixed by keeping the
URL current.

That also revises the direction agreed on #725. Dropping the URL was justified
there on the basis that it kept going stale on tags. It does not. The argument for
reconsidering it on main is that a fixed URL on a moving branch cannot hold an
invariant the generated code checks at runtime. Same conclusion for main,
different reason, and it no longer argues for touching the tags.

Worth noting separately: no current CI job resolves the published fallback, since
every iOS job sets TRUAPI_USE_LOCAL_BINARY: "1". A wrong URL or checksum in a
manifest pull request would pass CI. The checksum in #582 is correct, verified by
downloading the asset and computing it, but nothing in CI established that.