2026-04-25 xcodebuild test Code Coverage, xcresult to JUnit & PR Gates on Leased Cloud Mac (HK / JP / KR / SG / US)

iOS and macOS teams that already schedule headless xcodebuild test on a leased Apple Silicon Mac mini M4 often still merge pull requests on the strength of a single exit code and a red/green cell in the CI vendor UI. This 2026-04-25 guide closes the gap between “tests passed” and “we can explain what changed in quality this week” by standardizing: -resultBundlePath to a per-job directory under your isolated build root, -enableCodeCoverage YES to emit LLVM profdata, an export to JUnit XML (via xcresulttool or the vendor wrapper you trust), and a line-rate policy you enforce with xccov or your dashboard’s own parser. It intentionally complements—does not replace—the Test Plan + parallel xcresult runbook. Cross-link to Swift 6 strict concurrency for compiler-gate story; this article is the test-artifact and merge signal side of the same pipeline.

What a PR gate should see besides exit code 0

A healthy gate carries three bundles: (1) junit (or xunit) XML the PR system can annotate with per-test results and flakes; (2) a merged or single .xcresult you can open in Xcode for deep triage, stored as a compressed artifact with the same retention you use for xcresult isolation tickets; (3) a coverage summary (line or branch, per policy) you can diff against the merge-base so refactors that delete dead code are not treated as regression. In HK / JP / KR / SG / US where you may fan out to multiple SSH hosts, the gate must be defined on aggregated metrics when you shard by destination—never let one shard’s partial profdata be the only story unless your policy explicitly scopes coverage to a subset of targets. Pair timing numbers with the same machine pool label you print in metadata so product cannot compare a cold Simulator in Tokyo with a warm one in US East and call it a fair A/B test.

xcodebuild flags that matter: result bundle, coverage, destinations

Pin a single DEVELOPER_DIR=/Applications/Xcode.app and a Simulator -destination string you control, not a floating “latest iOS” you did not name. A minimal, explicit pattern:

DEVELOPER_DIR=/Applications/Xcode.app xcodebuild test -workspace App.xcworkspace -scheme App -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' -enableCodeCoverage YES -resultBundlePath "$CI_ROOT/Test-$(date +%s).xcresult" -derivedDataPath "$CI_DERIVED/job-$CI_JOB_ID" -parallel-testing-enabled YES CODE_SIGNING_ALLOWED=YES

Adjust -only-testing / -skip-testing in shard jobs; keep a coordinator job that knows how to merge. Set -retry-tests-on-failure only with a flake budget written down—an infinite retry loop is how green builds hide a broken keychain setup that the signing article already warns about. If you are already running a separate Swift 6 strict stage, do not double-count the same unit tests in both lanes unless the scheme split is real—duplicate coverage is wasted minutes on shared NVMe.

From .xcresult to JUnit: export path that survives headless

CI hosts running macOS expose xcresulttool: export tests and diagnostics as structured JSON or JUnit, depending on flags available in your pinned Xcode. Common workflow: (1) ensure the path you pass to -resultBundlePath is unique per run and lives under a directory that is not a symlink to a shared NFS mount; (2) xcresulttool get --format json to sanity-check the bundle post-run; (3) convert to JUnit for your provider—many orgs use a thin Ruby or Node adapter they vendor-lock; the important part is a stable testsuite name and classname for each testcase so the PR UI can de-duplicate retries. If you merge multiple xcresult bundles, prefer Xcode’s merge support or a documented order (timestamp ascending) and reject merges when two bundles show conflicting testStatus for the same identifier. Ship the raw xcresult to cold storage the same way you do for simulator triage, not only the XML.

LLVM profdata, xccov, and thresholds you can defend

With -enableCodeCoverage YES, the compiler and linker produce coverage data you merge with xcrun llvm-profdata merge and inspect with xcrun xccov view --report or report modes appropriate to your policy. A pragmatic policy: establish a floor on the application and core framework modules you own, and exclude generated / third-party targets with explicit exclusion lists checked in—unlisted third-party code should not silently absorb your team’s budget. Reconcile numbers after self-hosted runner moves: the same git SHA on two hosts should produce the same hash of source files, but incremental coverage may differ if one host skipped a target—another reason the strict lane may disable incremental entirely. If you upload dSYMs in the same night as a coverage change, make sure the dSYM pipeline still matches the bitcode/LLVM build products you think you shipped.

Sharded test jobs: merge before you gate

When you split by -only-testing:Target/Class or by destination, each shard produces its own profdata and xcresult. A merge-gate in the coordinator should: (1) verify every shard ended and uploaded artifacts; (2) merge profdata before a single xccov call; (3) aggregate JUnit, marking skipped suites intentionally absent from a shard. If a shard is lost to an infra preemption, treat the merge as failed unless your policy has a written “acceptable missing shard” rule—rare, and not the default. This pattern pairs with the M4 fan-out article: more concurrency only helps if your data plane (artifacts + coverage) is serializable back into one report.

Symptom / layer / fix

Symptom	Layer	Fix / verify
Coverage 0% but tests ran	Build settings / target membership	Check Code Coverage is enabled in scheme, targets compile with coverage flags
JUnit empty, UI shows “passed”	Tooling export	Validate xcresulttool output on host version; do not trust vendor stub
Two hosts: huge line-rate delta	Branch / incremental / shard	Disable incremental for the gate; merge profdata; pin destinations

Related runbooks and automation on the same host

If this Mac also runs a OpenClaw gateway, do not share a single /tmp between agents—your TMPDIR should already be per job. For shipping builds, remote archive and IPA export with App Store Connect API are downstream consumers of the same identity of trust: tests+coverage in CI should be on the same branch identity you tag for release, modulo promotion delays you document.

FAQ: quality gates in multi-region Mac pools

Question	Practical answer
Should I block on branch coverage?	Only if your language mix can support it; line rate is easier to sell to PMs, branch for critical security modules.
How long to keep xcresult zips?	Align to your incident SLA—14+ days is a common start; 1–2 TB leases make longer retention possible.
US East first or Asia first in the matrix?	Pick the region closest to the majority of committers for interactive repro; run the full matrix on release.

Why lease Mac mini M4 for this workload

Simulator and coverage jobs are CPU+NVMe+inode bound more often than they are GPU bound. A bare-metal Mac mini M4 in MacXCode’s regions offers predictable I/O and enough RAM to keep multiple CoreSimulator roots warm without a noisy neighbor on the same host as your OpenClaw gateway. When a region needs a second lane for p95, scale via the plan page instead of piling three unrelated teams onto a single 512 GB volume. If you need a human to verify GUI only occasionally, VNC remains a break-glass path—SSH + artifacts should carry the day for 2026 weekly cadence.