ci: Xcode 26.6 / simulator 26.5, and Swift 6.4 in the ubuntu matrix

[leogdion]

Two related CI changes. The original description only covered the first; this covers the whole diff.

1. Xcode 26.6 / simulator runtime 26.5

The macos-26 runner image now defaults to Xcode 26.6 (17F113), and its preinstalled simulator runtimes are 26.5 on iOS, watchOS, tvOS, and visionOS. The workflows were pinned to Xcode_26.4.app with runtimes 26.4/26.4.1 — two Xcode releases behind, and those runtimes are no longer preinstalled.

File	Change
.github/workflows/MistKit.yml	Xcode_26.4.app → 26.6; four osVersion pins → 26.5
.github/workflows/MistDemo.yml	same
.github/workflows/codeql.yml	xcode-select path → Xcode_26.6.app
Examples/BushelCloud/.github/workflows/BushelCloud.yml	same as the root workflows
Examples/BushelCloud/.github/workflows/codeql.yml	Xcode_26.2.app → 26.6

Two notes on that table:

• BushelCloud's codeql.yml jumps 26.2 → 26.6, a bigger delta than everything else. That is intentional catch-up, not a typo — that one job had drifted two releases further back than the rest of the repo.
• CelestraCloud was already on 26.6 / 26.5 and needed no edit.

Device names are unchanged: iPhone 17 Pro, Apple Watch Ultra 3 (49mm), Apple TV, and Apple Vision Pro are all still listed under the 26.5 runtimes for Xcode 26.6.

The macos-15 compat lane is deliberately untouched

MistKit.yml's build-macos-platforms keeps its macos-15 entries — Xcode 16.4 SPM, Xcode 16.3 SPM, and iOS on iPhone 16 @ 18.4. Verified against the current macos-15-arm64 manifest that Xcode 16.3 still ships there with a matching iOS 18.4 runtime, so the lane is still valid. It is the only older-toolchain signal in the repo.

2. Swift 6.4 in the build-ubuntu matrix

Adds the in-development Swift 6.4 branch to build-ubuntu in MistKit.yml, MistDemo.yml, BushelCloud.yml, and CelestraCloud.yml, following the shape ConfigKeyKit already uses.

Swift matrix entries gain an optional image key, and the snapshot entry carries it:

{"version":"6.4","image":"swiftlang/swift:nightly-6.4.x"}

The container is then resolved with a fallback expression so stable and snapshot entries share one job:

container: ${{ matrix.swift.image
  && format('{0}-{1}', matrix.swift.image, matrix.os)
  || format('swift:{0}-{1}', matrix.swift.version, matrix.os) }}

Two registry details drive that indirection:

• The official swift image publishes no nightly tags at all, so snapshots must come from the swiftlang/swift registry.
• The tag is nightly-6.4.x-<distro>. nightly-6.4-noble does not exist.

Supporting changes:

• MistDemo.yml, BushelCloud.yml, and CelestraCloud.yml carried their ubuntu swift versions as bare strings, so those move to the same object shape, and their Codecov flags: follow from matrix.swift to matrix.swift.version.
• Where the ubuntu matrix has a type dimension (MistKit.yml, MistDemo.yml), 6.4 is excluded from wasm and wasm-embedded — Swift nightly publishes no matching Wasm SDK snapshot. BushelCloud and CelestraCloud have no type dimension, so they need no exclude.
• Only the full matrix carries the 6.4 entry; the quick matrix stays on one stable version.

Verification

• MistKit builds clean under Swift 6.4. Installed swift-6.4.x-DEVELOPMENT-SNAPSHOT-2026-08-14-a on Ubuntu 24.04 and built the package: Build complete!, exit 0.
• The 26.5 runtime strings are correct. All four platforms under Xcode 26.6 are exactly 26.5 with no patch component, per the macos-26-arm64 image manifest. This matters because iOS and visionOS previously pinned 26.4.1 while watchOS and tvOS pinned 26.4, so the flattening is a real change and a wrong string fails the simulator boot outright.
• download-platform: true is retained deliberately. brightdigit/swift-build runs xcodebuild -downloadPlatform <platform> unconditionally and lets Xcode no-op when the runtime is already installed, so it is a cheap check rather than a fetch. Keeping it means the matrix still works if a future image drops a runtime.
• All workflow files parse as YAML; no bare matrix.swift references remain anywhere.

Known trade-off

swiftlang/swift:nightly-6.4.x is a floating tag, and the 6.4 cell is a normal blocking matrix entry with no continue-on-error — matching the ConfigKeyKit precedent. A Swift 6.4 snapshot regression can therefore redden unrelated PRs. Accepted deliberately; worth revisiting if it proves noisy in practice.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: e3aab546-348f-47b3-b075-2254510ff2a6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Review

Pure CI-config change — mechanical version bump across the three root workflow files, no source/test changes involved. Went through it against CLAUDE.md conventions and the actual diff.

Code quality / correctness

• The Xcode_26.4.app → Xcode_26.6.app and osVersion: 26.4/26.4.1 → 26.5 substitutions are applied consistently across all matrix entries in MistKit.yml, MistDemo.yml, and codeql.yml. No stray/missed occurrences in these three files.
• The macos-15 backward-compat lane (Xcode 16.4/16.3, iPhone 16 @ 18.4) is correctly left untouched, matching the PR description's stated intent.
• Examples/BushelCloud/ still pins Xcode_26.4.app/26.4.1/26.4 (and its own codeql.yml pins Xcode_26.2.app), and Examples/CelestraCloud/ was already on 26.6 before this PR. Worth a one-line confirmation in the PR that per-example CI is intentionally decoupled from the root lanes (seems consistent with the "Examples dogfood MistKit independently" structure in CLAUDE.md), so a future reader doesn't read the BushelCloud gap as an oversight.

Potential issue — undercuts the PR's own stated goal

• The PR body's rationale is: pin to the Xcode/runtime combo that's preinstalled on the macos-26 image so lanes stop paying a download-platform fetch. But every simulator matrix entry (iOS, watchOS, tvOS, visionOS in both MistKit.yml and MistDemo.yml) still carries download-platform: true unconditionally. If runtime 26.5 really is preinstalled with Xcode 26.6 as described, that flag is now dead weight and the CI-time win described in the PR body won't actually materialize until it's dropped (or made conditional) for the macos-26 lanes. Worth either removing it for the newly-preinstalled lanes or confirming via brightdigit/swift-build's implementation that download-platform: true is a cheap no-op when the runtime is already present — as written, the diff doesn't confirm which is true.
• Relatedly, the "26.5 is preinstalled on the macos-26 image with Xcode 26.6" claim is asserted in the PR description but isn't independently verifiable from this diff alone — worth double-checking against GitHub's actions/runner-images changelog for the macos-26 image before merging, since a wrong pairing would fail the simulator boot (mitigated somewhat by download-platform: true still being set, but that's the flag flagged above).

Performance

• If the preinstalled-runtime premise holds and download-platform: true is trimmed, this should meaningfully cut simulator-lane setup time. As currently written (flag left on), the wall-clock benefit is unclear.

Security

• No concerns — no secrets, permissions, or third-party action pins changed.

Test coverage

• N/A for a workflow-only change; correctness here is best confirmed by watching the actual CI run on this PR (all lanes green, and ideally faster / without a platform-download step for the macos-26 lanes) rather than by unit tests.

Overall: safe, well-scoped mechanical bump. The main thing I'd want resolved before merge is the download-platform: true question above, since it's the crux of the stated motivation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (v1.0.0-beta.4@8834dcf). Learn more about missing BASE report.

Additional details and impacted files

@@               Coverage Diff                @@
##             v1.0.0-beta.4     #432   +/-   ##
================================================
  Coverage                 ?   76.22%           
================================================
  Files                    ?      158           
  Lines                    ?     3761           
  Branches                 ?        0           
================================================
  Hits                     ?     2867           
  Misses                   ?      894           
  Partials                 ?        0           

Flag	Coverage Δ
mistdemo-spm-macos	11.30% <ø> (?)
mistdemo-swift-6.2-jammy	11.30% <ø> (?)
mistdemo-swift-6.2-noble	11.30% <ø> (?)
mistdemo-swift-6.3-jammy	11.30% <ø> (?)
mistdemo-swift-6.3-noble	11.30% <ø> (?)
mistdemo-swift-6.4-jammy	11.43% <ø> (?)
mistdemo-swift-6.4-noble	11.30% <ø> (?)
spm	74.20% <ø> (?)
swift-6.1-jammy	74.38% <ø> (?)
swift-6.1-noble	74.54% <ø> (?)
swift-6.2-jammy	74.28% <ø> (?)
swift-6.2-noble	74.22% <ø> (?)
swift-6.3-jammy	74.01% <ø> (?)
swift-6.3-noble	74.25% <ø> (?)
swift-6.4-jammy	74.09% <ø> (?)
swift-6.4-noble	74.09% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[claude]

Review: ci: update macOS lanes to Xcode 26.6 and simulator runtime 26.5

Reviewed the diff (9 files) against the PR description and CLAUDE.md conventions.

Scope vs. description

The PR body only describes the Xcode 26.4→26.6 / simulator 26.4→26.5 bump, but the actual diff also bundles a second, unrelated change: adding a Swift 6.4 nightly-snapshot entry to the build-ubuntu matrix across MistKit.yml, MistDemo.yml, BushelCloud.yml, and CelestraCloud.yml (plus the .claude/agent-notes.md / .claude/memory/ updates documenting that decision). Worth updating the PR description to cover both changes (or splitting into two PRs) so reviewers/changelog readers aren't surprised by half the diff.

Potential issues

• Examples/BushelCloud/.github/workflows/codeql.yml: jumps straight from Xcode_26.2.app to Xcode_26.6.app — a bigger, unexplained delta than the "26.4→26.6" narrative in the PR body (this file was already two releases further behind than the others). Worth a one-line callout in the description confirming 26.6 is intentional here too, not a typo.
• download-platform: true left on for all four simulator lanes (iOS/watchOS/tvOS/visionOS) in both MistKit.yml and MistDemo.yml. The PR's own rationale is that Xcode 26.6 now preinstalls the 26.5 runtimes, which is exactly what made the old pin costly (extra download-platform fetch every run). If that's true, these lanes could now drop download-platform: true entirely to actually realize the CI-time savings described in the body — as written, the fetch step still runs (presumably a fast no-op if already present, but worth confirming rather than assuming).
• Simulator version strings flattened: previously iOS/visionOS pinned 26.4.1 while watchOS/tvOS pinned plain 26.4. All four are now uniformly 26.5 with no patch suffix. Given Xcode's runtime versioning isn't always uniform across platforms, it's worth double-checking Apple's Xcode 26.6 release notes confirm all four platforms really do ship exactly 26.5 (not 26.5.1 for some) before merging — a mismatched runtime string fails the simulator boot step outright rather than degrading gracefully.

Nice-to-haves confirmed correct

• The container: ${{ matrix.swift.image && format(...) || format(...) }} fallback expression is applied consistently across all four workflow files, and the pre-existing wasm/wasm-embedded exclusion pattern for the 6.1 special case is correctly mirrored for the new 6.4 entry in both MistKit.yml and MistDemo.yml (checked BushelCloud.yml/CelestraCloud.yml too — they don't build wasm at all, so no exclude needed there, which is correct).
• Grepped all four workflows for lingering bare matrix.swift references (would break now that it's an object) — none found; every reference was already updated to matrix.swift.version or matrix.swift.image as appropriate, including the Codecov flags: lines.
• The new Swift 6.4 job is a blocking matrix cell (no continue-on-error), matching the ConfigKeyKit precedent the memory notes cite. Flagging this explicitly since it's a real trade-off: swiftlang/swift:nightly-6.4.x is a floating, unpinned tag — its contents can change between runs, so an unrelated PR could start failing CI if a Swift 6.4 snapshot regresses, with no advisory-only escape hatch. Sounds like this was already discussed and intentionally accepted (per .claude/memory/feedback_ci_swift_matrix.md), just flagging for visibility in case the trade-off needs revisiting once it's seen a few real breakages.

Security

No new secrets or permissions introduced. The one new external dependency is the floating swiftlang/swift:nightly-6.4.x Docker tag (unpinned by digest) — consistent with how the repo already references stable swift:* tags, but nightlies are more volatile; not a blocker, just noted alongside the reliability point above.

Test coverage

This is CI-config only, so "test coverage" isn't really applicable — the only real validation is a green run of the actual GitHub Actions pipeline. Worth watching the first run closely, especially the new nightly-toolchain cell and the flattened simulator osVersion values, since both are easy to get subtly wrong in ways that only surface at CI runtime.

Overall this is a clean, low-risk config bump with good internal consistency (matrix shape, exclusions, and codecov flags all updated in lockstep). The main asks are: reconcile the PR description with the full diff, and double-check the two data-fact items (BushelCloud's codeql Xcode jump and the flattened 26.5 runtime strings) against Apple's actual Xcode 26.6 release notes before merging.

[claude]

Review

Reviewed the diff and cross-checked the YAML for consistency. This is a clean, well-scoped CI-only change — no code in Sources//Tests/ touched, so the usual FieldValue/CloudKitService concerns don't apply here.

What checks out

• container: fallback expression (matrix.swift.image && format(...) || format(...)) is correct GitHub Actions short-circuit semantics: an undefined matrix.swift.image evaluates to a falsy null, so the expression correctly falls through to the swift:{version}-{os} form for stable entries. Verified this pattern is applied identically and correctly across MistKit.yml, MistDemo.yml, BushelCloud.yml, and CelestraCloud.yml.
• No bare matrix.swift references remain — grepped the whole workflow tree for matrix\.swift\b not followed by . and got zero hits, matching the PR body's claim.
• exclude: entries for the 6.4 snapshot follow the exact same shape as the existing 6.1 wasm excludes (swift: { version: "6.4", image: "..." } / type: "wasm"), so they should match GitHub's deep-equality exclude semantics the same way the pre-existing 6.1 excludes already do.
• No stray 26.4/26.2 Xcode pins left behind — grepped for both and found none, so the bump is complete across all five workflow files listed in the PR body.
• Codecov flags correctly moved from matrix.swift to matrix.swift.version everywhere the matrix shape changed (MistDemo, BushelCloud, CelestraCloud), avoiding a flag string like swift-[object Object]-noble.
• The .claude/agent-notes.md and .claude/memory/feedback_ci_swift_matrix.md updates are good practice here — they explicitly supersede the two prior (contradictory) directives about nightly toolchains, with the "why" preserved, which avoids the next session re-litigating this.

Worth a second pair of eyes (not blockers, mostly already acknowledged in the PR body)

1. Floating tag + blocking matrix cell. swiftlang/swift:nightly-6.4.x is a mutable tag and the new matrix cell has no continue-on-error, so an upstream Swift nightly regression will redden CI on unrelated PRs with no way to distinguish "nightly regressed" from "this PR broke something." This is called out explicitly as an accepted trade-off, so just flagging that it's a real operational cost, not a hypothetical — worth a quick check-in after a few weeks to see how noisy it actually is in practice.
2. osVersion: "26.5" / Xcode_26.6.app pins are asserted, not verified in CI. The PR body says these were checked against the current macos-26-arm64 runner manifest, which is reasonable, but that manifest is a moving target on GitHub-hosted runners — if it drifts again there's no automated signal until a run fails on xcrun simctl being unable to find the runtime. Not something to fix in this PR, just noting there's no guardrail against the next drift.
3. Minor: three near-identical container:/exclude blocks now duplicated across 4 files. (MistKit.yml, MistDemo.yml, BushelCloud.yml, CelestraCloud.yml all carry the same image-fallback expression verbatim.) Not a real problem for GitHub Actions workflows (there's no clean cross-repo shared-workflow story here without a reusable workflow file), but if a fifth workspace picks up the same pattern later, a reusable workflow (workflow_call) might be worth considering to avoid drift between copies.

Security / test coverage

No security concerns — this only touches CI runner/toolchain pins and doesn't change trigger permissions, secrets handling, or third-party action versions. Test coverage doesn't apply in the traditional sense (no product code changed); the real "test" of this PR is whether the new matrix cells actually go green on GitHub's runners, which can't be verified from the diff alone.

Overall: solid, well-documented change. Nothing here blocks merging.