ci: collapse iOS scheme matrix into single sequential job

[atom2ueki]

Summary

• Replace the strategy.matrix over [CodingPlanAuth, CodingPlanCodex] in the ios-build job with a single job that runs both xcodebuild invocations sequentially.
• Removes one parallel macOS runner per push/PR — each runner paid a full boot/checkout/Xcode-warmup before doing real work, so two runners cost ~2x macOS minutes for ~the same signal. Sequential reuses warm DerivedData between builds.
• Preserves the previous fail-fast: false behavior by gating the second build on if: always() && steps.build_auth.conclusion != 'cancelled' so a CodingPlanAuth failure no longer hides a CodingPlanCodex failure.

Test plan

• CI runs on this PR and the single Build for iOS Simulator job builds both schemes successfully.
• Manually verify the if: always() gate by inspecting the workflow run — both build steps should appear regardless of the first step's outcome.
• spm and docc jobs still run (no incidental changes to those).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 04c89cb7e8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Code Review

Overall: Looks good — clean, well-motivated change.

What this does

Collapses the two-scheme strategy.matrix iOS build into a single job with two sequential xcodebuild steps. The key benefits are correct: one macOS runner boot instead of two, and warm DerivedData reuse between builds.

Strengths

• The fail-fast: false semantics are preserved correctly: a CodingPlanAuth failure still lets CodingPlanCodex run and report independently.
• Removing the SCHEME env var that was only meaningful inside the matrix is the right cleanup.
• Sharing -derivedDataPath .derivedData between the two steps is the main practical win and works as described.
• The docc and spm jobs are untouched — no unintended scope creep.

Suggestions

1. if condition — consider the idiomatic alternative (non-blocking)

The current condition if: always() && steps.build_auth.conclusion != 'cancelled' is correct but GitHub Actions has a more conventional spelling for "run on all non-cancelled states":

if: success() || failure()

Both are equivalent here (success() || failure() is false only when the job is cancelled), but the built-in status functions are what most readers will reach for first. Either form is fine.

2. Timeout may be tight (worth watching)

The timeout is still 25 minutes. Previously each matrix job had its own 25-minute budget; now both builds share one budget sequentially. DerivedData reuse should help the second build significantly, but if either build was previously running close to 12–13 minutes, the combined run could approach the limit. Worth keeping an eye on the first few CI runs and bumping to 35 minutes if needed.

3. No DerivedData cache across runs (minor / out of scope)

The spm and docc jobs cache .build with actions/cache. The ios-build job doesn't cache .derivedData, so every run starts cold. This PR doesn't regress anything here (status quo), but a cache step would be a natural follow-up if build times are still slow.

Verdict

The logic is sound and the trade-off (sequential latency vs. halved macOS minutes) is well-justified for a project at this scale. No blocking issues.