Claude Code × Xcode Cloud — A One-Week Migration of ci_scripts and TestFlight Auto-Delivery

ci_post_clone.sh — warming up dependencies

My project uses both CocoaPods and Swift Package Manager. Xcode Cloud handles SwiftPM resolution automatically, but CocoaPods needs an explicit pod install. The shape I settled on:

#!/bin/sh -e
 
WORKSPACE="${CI_WORKSPACE:-$(pwd)}"
cd "$WORKSPACE"
 
echo "[ci_post_clone] node $(node --version 2>/dev/null || echo 'not installed')"
echo "[ci_post_clone] xcode-select: $(xcode-select -p)"
 
# CocoaPods is not part of the Xcode Cloud image.
if ! command -v pod >/dev/null 2>&1; then
  echo "[ci_post_clone] installing cocoapods via brew"
  brew install cocoapods >/dev/null
fi
 
# Branch on whether Podfile.lock exists.
if [ -f "Podfile.lock" ]; then
  pod install --deployment --repo-update
else
  pod install --repo-update
fi
 
echo "[ci_post_clone] done"

One trap to call out: pod install can fail with xcrun: error: invalid active developer path if the Xcode Cloud image has several Xcode versions and xcode-select does not know which one is active. I was tempted to fix this with sudo xcode-select -s /Applications/Xcode.app/Contents/Developer, but pinning the Xcode version inside the Xcode Cloud workflow ("Xcode 26.3" in my case) is the right answer. Avoid the temptation to solve it inside the script — that was my conclusion with Claude Code at the time.

ci_pre_xcodebuild.sh — getting secrets into the build

My apps inject a GoogleService-Info.plist for Firebase, an AdMob App ID, and a Stripe publishable key through .xcconfig at build time. None of those values belong in the repository, so under Xcode Cloud I register them as environment variables and assemble the .xcconfig inside ci_pre_xcodebuild.sh.

This was the most frustrating part of the migration away from Fastlane match. My old scripts assumed a .env.ci file would auto-load via dotenv. The first version Claude Code produced still carried that habit, and it bit me.

Before — still living in the Fastlane world:

#!/bin/sh -e
 
# Assumes .env.ci will auto-load (does not work on Xcode Cloud)
if [ -f "$CI_WORKSPACE/.env.ci" ]; then
  set -a
  . "$CI_WORKSPACE/.env.ci"
  set +a
fi
 
cat > "$CI_WORKSPACE/Config/Secrets.xcconfig" <<EOF
ADMOB_APP_ID = $ADMOB_APP_ID
STRIPE_PUBLISHABLE_KEY = $STRIPE_PUBLISHABLE_KEY
EOF

This passed locally with a .env.ci present, so the initial PR looked green. The moment I pushed to Xcode Cloud, ADMOB_APP_ID came through as an empty string, an empty .xcconfig got written, and AdMob initialization blew up with Invalid Application ID on real devices. Crashlytics caught it before users did, but only just.

After — trust the Xcode Cloud environment variables and fail loudly:

#!/bin/sh -e
 
WORKSPACE="${CI_WORKSPACE:-$(pwd)}"
cd "$WORKSPACE"
 
# On Xcode Cloud, env vars are already exported by the runtime.
# If anything is missing, halt the build instead of writing an empty .xcconfig.
require_env() {
  name="$1"
  value=$(eval echo "\$$name")
  if [ -z "$value" ]; then
    echo "[ci_pre_xcodebuild] required env not set: $name" >&2
    exit 64
  fi
}
 
require_env ADMOB_APP_ID
require_env STRIPE_PUBLISHABLE_KEY
require_env FIREBASE_DATABASE_URL
 
mkdir -p "Config"
cat > "Config/Secrets.xcconfig" <<EOF
// Generated by ci_pre_xcodebuild.sh - DO NOT EDIT
ADMOB_APP_ID = $ADMOB_APP_ID
STRIPE_PUBLISHABLE_KEY = $STRIPE_PUBLISHABLE_KEY
FIREBASE_DATABASE_URL = $FIREBASE_DATABASE_URL
EOF
 
echo "[ci_pre_xcodebuild] secrets.xcconfig generated"

The key change is the require_env helper. When moving off Fastlane match, delete every code path that reads .env.ci, and add an explicit exit 64 for any missing variable. An empty .xcconfig lets the build succeed, lets the binary upload to TestFlight, and then breaks on real user devices. That is the worst possible failure mode.

Apple's .xcconfig syntax treats // and everything after it as a comment, so a value with // in it (like a URL) will silently lose half of itself. I now keep URLs out of .xcconfig entirely and rebuild them in Swift from a base key plus the bundle identifier.

ci_post_xcodebuild.sh — dSYM upload without breaking the workflow

TestFlight delivery works at this point. The remaining task is uploading dSYM files to Firebase Crashlytics. Without dSYMs (symbol information), crash reports degrade to raw memory addresses and become useless.

Xcode Cloud is post-bitcode, so dSYMs land in $CI_ARCHIVE_PATH/dSYMs/ as part of xcodebuild. We call Firebase's upload-symbols script from ci_post_xcodebuild.sh.

#!/bin/sh -e
 
WORKSPACE="${CI_WORKSPACE:-$(pwd)}"
cd "$WORKSPACE"
 
# Failed builds may not have a dSYM directory. Bail cleanly.
if [ "$CI_XCODEBUILD_EXIT_CODE" != "0" ]; then
  echo "[ci_post_xcodebuild] xcodebuild failed (exit=$CI_XCODEBUILD_EXIT_CODE), skipping dSYM upload"
  exit 0
fi
 
# Only run dSYM upload on delivery workflows.
if [ "$CI_WORKFLOW" != "TestFlight Beta" ] && [ "$CI_WORKFLOW" != "Production" ]; then
  echo "[ci_post_xcodebuild] workflow=$CI_WORKFLOW, skipping dSYM upload"
  exit 0
fi
 
DSYMS_DIR="$CI_ARCHIVE_PATH/dSYMs"
if [ ! -d "$DSYMS_DIR" ]; then
  echo "[ci_post_xcodebuild] dSYMs directory not found at $DSYMS_DIR"
  exit 0
fi
 
UPLOAD_SYMBOLS="$WORKSPACE/Pods/FirebaseCrashlytics/upload-symbols"
if [ ! -x "$UPLOAD_SYMBOLS" ]; then
  echo "[ci_post_xcodebuild] upload-symbols not found, did pod install run?"
  exit 0
fi
 
"$UPLOAD_SYMBOLS" \
  -gsp "$WORKSPACE/Apps/Wallpaper/GoogleService-Info.plist" \
  -p ios \
  "$DSYMS_DIR"
 
echo "[ci_post_xcodebuild] dSYM upload completed"

Two points worth pausing on. First, the heavy use of exit 0. A non-zero exit in ci_post_xcodebuild.sh marks the entire build as failed, even if TestFlight delivery already succeeded. dSYM upload is auxiliary, so the failure should log loudly but never sink the parent build.

Second, the CI_WORKFLOW branch. I defined three workflows — "Pull Request," "TestFlight Beta," and "Production." Pull Requests do not deliver to TestFlight and do not upload dSYMs. The first version I shipped lacked this branch, and every PR build dumped a fresh symbol set into Firebase. The symbol history page filled up with PR builds within a day. Add the branch from the start.

Three workflows: Pull Request, TestFlight Beta, Production

Xcode Cloud workflows are defined in the App Store Connect GUI, not as text in xcshareddata/xcschemes/. The configuration lives on Apple's servers as project-external metadata. If you want a backup, screenshot the GUI into Notion or Dropbox — there is no first-class export.

The split I run:

• Pull Request — Trigger: PR open/update. Action: build + unit tests. No delivery.
• TestFlight Beta — Trigger: push to develop. Action: build + TestFlight (Internal Group) + dSYM upload.
• Production — Trigger: tag push v*. Action: build + TestFlight (External Group) + dSYM upload + Slack notification.

Only Production has a Slack notification, for one reason: External Group delivery goes through Apple's Beta App Review, which adds a few hours to a day of latency. Internal Group delivery is immediate, so the TestFlight app's native notification is enough.

A week of running it: the three failures that mattered

After one week of real runs I had collected three failures worth recording.

The first failure was leaving the "Start Condition" set to "Auto" on every branch for the first three days. Every push to a feature/* branch fired the TestFlight Internal workflow, and the team's TestFlight app filled up with builds nobody should be testing. The fix is a "Branch Starts With: develop" filter; obvious in hindsight, but the GUI defaults to the most permissive setting.

The second failure was discovering that "Continue on script failure" was on for the workflow, so my exit 64 in ci_pre_xcodebuild.sh did not actually halt the build — TestFlight got an empty-secrets binary. Internal Group only, so no external blast radius, but it took until the Crashlytics report came in to notice. Turn "Continue on script failure" off. Script failures should always halt the build.

The third failure was a slow creep in build time. The first TestFlight Beta workflow took fourteen minutes; I had to get it under ten to live with it. With Claude Code I tried a few knobs. The three that mattered, in order of impact, were dropping --repo-update from the default pod install and running it manually only when needed (around three minutes saved), turning on the Xcode Cloud option to reuse the SwiftPM cache under ~/Library/Developer/Xcode/DerivedData/ (about two minutes), and splitting tests into a "Smoke" and a "Full" suite and switching between them based on the trigger (another three minutes). The final number sits at six minutes.

Closing thoughts

Fastlane match is a tool I had touched for close to ten years, and walking away from it was harder than I expected. In the end Fastlane stays for two things only: emergency local deliveries and automated screenshot capture. Every regular delivery path now goes through Xcode Cloud. The amount of mental space CI used to take from my weekday mornings dropped to almost zero.

Both of my grandfathers were master temple carpenters, and there is a quality to "everything aligns just a little better" that calms me. With less attention spent on CI, the attention available to think about what the apps should actually feel like came back. For a one-person operation, that is a bigger change than it looks on paper.

If you are considering the same move, my one piece of practical advice is to start by writing the three ci_scripts/ so they can dry-run locally with CI_WORKSPACE=$(pwd) bash -e ci_scripts/.... Once your CI lives as text rather than as GUI clicks, conversations with Claude Code lock in noticeably faster, and a week is genuinely enough to land it.

Thank you for reading this far. I hope it helps you if you are running iOS apps on your own.