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:

.package(url: "https://github.com/paritytech/host-rust-core", exact: "0.14.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. When the tag already exists recording the same tree — generated sources included, not just the manifest — it exits successfully, so a rerun of the release pushes the existing tag as a no-op; a tag recording anything different is an error that names the paths which differ. Deciding that on the manifest alone would let bindings regenerated at the same version pass as a no-op and leave consumers pinned to the old ones. Since those sources are git-ignored and git will not diff them until they are staged, the comparison stages them into a scratch index seeded from the tag, which leaves the caller's own index untouched.

release-ios.yml publishes the asset and the tag. release.yml calls it for a release: @parity/ios-host <version> subject, and it is also dispatchable on its own, matching release-android.yml. Dispatching it from a branch with a version like 0.14.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 touches no branch.

When called from the release flow, the job opens a pull request on release/ios-host-<version> that points the release branch's Package.swift at the new asset, and dispatches CI for it explicitly because events created with GITHUB_TOKEN do not start another workflow.

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) 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 leaves no ios/ diff to key on.

Notes

• tag-release.sh makes the release commit with -c commit.gpgsign=false. CI configures no signing, but the manual fallback runs on developer machines where it is often on globally, and a release commit's provenance is the tag rather than a signature.
• 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 matches the hand-written TrUAPIHost.swift.
• 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.
• tag-release.sh and the manifest step both assert that Package.swift reads TRUAPI_USE_LOCAL_BINARY from the environment, so a published manifest can never pin the local binary.

Verifying the release path

GitHub only exposes workflow_dispatch for workflows present on the default branch, so release-ios.yml 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 a pre-release to exercise the publish half (asset upload, tag push, resolution from GitHub by the app) needs this merged first.

[TarikGul]

Looks good, just two small nits