Build an Xcode Warning Baseline Gate on a Cloud Mac

An Xcode project maintained over many years often accumulates dozens of build warnings. Enabling SWIFT_TREAT_WARNINGS_AS_ERRORS at that point can immediately make the main branch unbuildable. Ignoring the problem, however, allows new warnings to disappear into the existing noise. A more practical approach is to freeze a reviewed warning baseline on a cloud Mac and configure CI to reject only entries introduced by the current change.

Define the gate boundary

A warning gate should not simply count occurrences of warning: in the log. Dependency downloads, build scripts, and system tools can all emit the same text. A raw count is unstable and does not tell developers which file they need to change.

Normalize each warning as “repository-relative path + warning text,” removing line and column numbers, temporary directories, and timestamps. Moving code within a file then produces no new signature, while renaming a file or changing the warning text still triggers a review.

The baseline represents “currently known and accepted technical debt.” It does not mean those warnings are correct. Whenever an existing warning is removed, the baseline should shrink with it.

Generate reproducible warning signatures

First, pin the workspace, Scheme, configuration, and SDK. If developer machines use Debug while CI uses Release, conditional compilation can take different paths, making the resulting baselines meaningless to compare. The following script requires callers to provide the workspace and Scheme explicitly and saves the complete output.

#!/bin/bash
set -u

WORKSPACE="${WORKSPACE:?set WORKSPACE}"
SCHEME="${SCHEME:?set SCHEME}"
ROOT="$(git rev-parse --show-toplevel)"
OUT="$ROOT/.ci-artifacts"
DERIVED="$OUT/DerivedData"

mkdir -p "$OUT"
rm -rf "$DERIVED"

set +e
xcodebuild \
  -workspace "$WORKSPACE" \
  -scheme "$SCHEME" \
  -configuration Release \
  -sdk iphoneos \
  -derivedDataPath "$DERIVED" \
  CODE_SIGNING_ALLOWED=NO \
  build 2>&1 | tee "$OUT/xcodebuild.log"
BUILD_STATUS=${PIPESTATUS[0]}
set -e

grep -F "$ROOT/" "$OUT/xcodebuild.log" \
  | grep " warning: " \
  | sed "s#${ROOT}/##" \
  | sed -E 's#:[0-9]+:[0-9]+: warning: # | #' \
  | LC_ALL=C sort -u \
  > "$OUT/warnings.current"

exit "$BUILD_STATUS"

CODE_SIGNING_ALLOWED=NO is appropriate for jobs that only verify compilation. Pipelines that archive builds or validate signatures should not copy this setting unchanged. Build failures and warning regressions must also be handled separately: if xcodebuild itself fails, its exit code should take precedence rather than allowing an empty warning file to hide the real failure.

Handle script output and multiline diagnostics

Some Run Script phases emit custom warnings whose format may not include source coordinates. If the team maintains those scripts, assign them a fixed prefix and add a second parsing rule. Do not use one broad regular expression to capture all output, or network notices and tool upgrade notifications will also enter the baseline.

Swift’s supplementary diagnostic lines usually do not contain warning: and are unsuitable as standalone signatures, but they should remain in the full log. The gate provides a quick decision, while the full log preserves the context. Neither can replace the other.

Review and commit the initial baseline

The first generated warnings.current file should not be copied directly into the baseline by an automated job. First assign owners by path, remove duplicates, and confirm that generated files, dependency source code, and temporary directories have not been included. After completing the review, run:

mkdir -p .ci
LC_ALL=C sort -u .ci-artifacts/warnings.current > .ci/xcode-warnings.baseline
git add .ci/xcode-warnings.baseline
git commit -m "Add reviewed Xcode warning baseline"

The baseline must be versioned alongside the code. Any commit that expands it should show the new signatures and explain why they are being added. A failed job must never automatically “learn” new warnings, or the gate will bypass itself precisely when it is needed most.

When upgrading Xcode, the compiler may change the wording of its diagnostics. The correct process is to run a full build on a separate branch, distinguish genuinely new issues from wording changes, then update the baseline once and record the toolchain version. Do not compensate by adding increasingly permissive fuzzy matching to the comparison script.

Block only new warnings in CI

After sorting both the current result and the baseline, use comm to find signatures that exist only in the current build:

BASELINE=".ci/xcode-warnings.baseline"
CURRENT=".ci-artifacts/warnings.current"
NEW=".ci-artifacts/warnings.new"

test -f "$BASELINE"
LC_ALL=C sort -u "$BASELINE" -o "$BASELINE"
LC_ALL=C sort -u "$CURRENT" -o "$CURRENT"
LC_ALL=C comm -13 "$BASELINE" "$CURRENT" > "$NEW"

if test -s "$NEW"; then
  printf '%s
' "New Xcode warnings detected:"
  cat "$NEW"
  exit 42
fi

Archive xcodebuild.log, warnings.current, and warnings.new together. Exit code 42 is only an internal team convention; what matters is presenting “build failure” and “new warnings” as separate causes. Once developers can see the path and warning text, they can complete the fix within a single feedback loop.

If multiple jobs build different Targets in parallel, generate separate results and merge, sort, and deduplicate them afterward. Do not allow multiple processes to write to the same file simultaneously, because truncation and interleaved writes can cause intermittent false results.

Keep shrinking the baseline instead of freezing it forever

After the gate is introduced, every fix for an existing warning should also remove the corresponding baseline line. A non-blocking check can identify entries that remain in the baseline but have disappeared from the current build, reminding contributors to clean them up as part of the same change. This keeps the baseline shrinking in one direction instead of turning it into a historical list that nobody understands.

Before relying on the gate, verify four items: whether CI and local environments use the same Xcode version; whether the Scheme includes the expected Targets; whether locale settings affect tool output; and whether repository path filtering covers all first-party source code. Each job should also create a fixed execution directory on its OnceMac node to avoid reusing logs and DerivedData from a previous build.

Once the baseline reaches zero, remove the difference comparison and enable the compiler’s warnings-as-errors policy. Until then, the baseline gate provides a realistic transition: it does not hide existing debt, and it does not allow new debt to keep growing.

Frequently asked questions