chore: untrack generated Rust and iOS outputs, generate on demand

[pgherveou]

Generated outputs are not tracked. The Rust dispatcher, wire table and wasm bridge, the UniFFI Swift bindings, the FFI headers and modulemaps, and the lockdown container bundle are git-ignored build outputs produced from the Rust crates on demand.

Producing the outputs

scripts/codegen.sh emits the Rust outputs, including the mod.rs that truapi-server declares with pub mod generated;. make setup runs it, make codegen regenerates on its own. Every Make target that compiles truapi-server depends on check-generated, which names the missing file and points at make codegen instead of letting the failure surface as error[E0583]: file not found for module 'generated'.

In CI the Codegen job produces them once and uploads the codegen-output artifact; every job that compiles truapi-server depends on that job and downloads it. ci-android, release-android and release-ios are separate workflows with no such job, so they run scripts/codegen.sh in place with TRUAPI_SKIP_PACKAGE_BUILD=1.

The Codegen job also gates that nothing generated is committed, with git ls-files -ci --exclude-standard over the whole repo.

How iOS consumers get the sources

SwiftPM resolves a package's source targets from the git checkout and has no way to fetch them from a release asset: binaryTarget accepts only .xcframework and .artifactbundle. So an iOS release is two artifacts.

artifact	carries	consumer sees it as
@parity/ios-host@<version> release asset	truapi_server.xcframework.zip	publishedBinaryURL + checksum
plain semver tag <version>	generated bindings, FFI headers, container bundle, manifest pointing at the asset	the thing they pin

Consumers pin the semver tag, unchanged from today:

.package(url: "https://github.com/paritytech/host-rust-core", exact: "0.12.0")

ios/truapi-host/scripts/tag-release.sh builds that commit. It reads the required paths out of Package.swift rather than repeating them, so the file set cannot drift from what SwiftPM looks for, and it refuses to tag an xcframework into git.

publish-ios moves out of release.yml into release-ios.yml, callable from the release flow and dispatchable on its own, matching release-android.yml. Dispatching it from a branch with a version like 0.12.0-beta.1 cuts an asset and a tag an app can pin, which is how an unmerged host change gets tested in the app. A dispatched run passes no manifest_branch and so rewrites no branch.

The job clones the tag and compiles it against the published asset before pushing, so a tag that cannot be resolved is never published.

What CI proves

iOS package (swift compile) now builds the tag rather than the working tree: it runs tag-release.sh, clones the result, diffs the cloned file set against the working tree under every declared path, and compiles the package and its test target from that clean clone. Compiling in place would pass on generated files the tag does not carry, which is the exact failure being guarded.

iOS bindings (uniffi) regenerates the Swift and provider bindings. With nothing committed to diff against, what it gates is that bindgen still produces a binding for every UniFFI-exposed type.

ios-swift's path filter names every crate the bindings are generated from (truapi, truapi-platform, truapi-server, truapi-provider) plus js/container/, because a protocol change no longer leaves an ios/ diff to key on.

Notes

• release.yml's manifest follow-up step guarded on ^let useLocalBinary = false$, but 9b708fb5 had replaced that line with the ProcessInfo form. Under set -euo pipefail the step could never pass, which is why main's manifest still names ios-host@0.7.0 while 0.11.0 is published. The guard now asserts the manifest reads the environment variable, which is the invariant that actually matters.
• Package.swift declares TrUAPIProvider as a source target, so its bindings have to exist even for a consumer that only imports TrUAPIHost. ios/truapi-provider/scripts/sync-bindings.sh produces them without Xcode or the iOS targets, and rebuild.sh delegates to it.
• .gitignore lists the three generated Swift filenames rather than truapi*.swift. Under core.ignorecase, which git sets by default on macOS, the glob also matched the hand-written TrUAPIHost.swift.
• sync-bindings.sh --check and the provider-swift-check target compared against committed files and are gone.
• The mod.rs emitted alongside dispatcher.rs and wire_table.rs has a golden fixture. It is the file that makes truapi-server parse, so losing it fails a test rather than the next build.

Verifying the release path

release-ios.yml is new, and GitHub only exposes workflow_dispatch for workflows present on the default branch, so it cannot be dispatched from this branch. The tag's content and buildability are covered on the PR by the iOS package (swift compile) job above. Cutting 0.12.0-beta.1 to exercise the publish half (asset upload, tag push, resolution from GitHub by the app) needs this merged first.