DEV Community

Todd Sullivan
Todd Sullivan

Posted on

Shipping to TestFlight Without Fastlane: Raw xcodebuild, Auto-Incrementing Builds, and One Neat Provisioning Trick

#ios #xcode #cicd #devops

Most iOS CI tutorials reach for Fastlane. It's the default assumption. And Fastlane is fine — but it's also another Ruby toolchain to maintain, another layer of abstraction between you and xcodebuild errors, and another thing that breaks when Xcode updates.

For a small side project, I wanted zero overhead. So I wrote a release script using plain xcodebuild and xcrun altool, and wired it into GitHub Actions. Here's what I learned.

The Setup

The app is a no-dependency iOS project (SwiftUI, SwiftData, zero SPM packages). One scheme, one target, distributes via the App Store. The goal: git push → trigger workflow → build, sign, upload to TestFlight.

Auto-incrementing build numbers for free:

BUILD_NUMBER="${1:-$(git -C "$REPO_ROOT" rev-list --count HEAD)}"
Enter fullscreen mode Exit fullscreen mode

That's it. Every commit bumps the count. No build number file to commit, no race conditions in CI, no manual tracking. Pass it straight into xcodebuild:

xcodebuild archive \
  ...
  CURRENT_PROJECT_VERSION="$BUILD_NUMBER"
Enter fullscreen mode Exit fullscreen mode

TestFlight requires monotonically increasing build numbers. Git commit count gives you that automatically. I've seen people use timestamps (too long), semver patch (manual), or a counter file in the repo (merge conflicts). Commit count is cleaner.

The Provisioning Problem — and the Fix

This is where most raw-xcodebuild scripts fall apart. The export step (xcodebuild -exportArchive) needs an ExportOptions.plist with the exact provisioning profile UUID. But the UUID changes every time you renew the profile.

The usual answer is "hardcode it in your plist and update manually." That's the kind of thing you forget for six months and then debug for two hours.

Better approach: extract the UUID from the archive you just built, then inject it at export time.

# Pull the embedded profile from the freshly-built archive
EMBEDDED="$ARCHIVE/Products/Applications/MyApp.app/embedded.mobileprovision"
PROFILE_UUID=$(security cms -D -i "$EMBEDDED" | plutil -extract UUID raw -)

# Copy it into the Provisioning Profiles directory (xcodebuild looks here)
cp -f "$EMBEDDED" "$HOME/Library/MobileDevice/Provisioning Profiles/$PROFILE_UUID.mobileprovision"

# Write a temp ExportOptions with the exact UUID from *this* archive
cp "$EXPORT_OPTIONS" "$EXPORT_OPTIONS_TMP"
plutil -replace "provisioningProfiles.com.example.myapp" \
  -string "$PROFILE_UUID" "$EXPORT_OPTIONS_TMP"

# Now export using that temp plist
xcodebuild -exportArchive \
  -archivePath "$ARCHIVE" \
  -exportPath "$EXPORT_DIR" \
  -exportOptionsPlist "$EXPORT_OPTIONS_TMP"
Enter fullscreen mode Exit fullscreen mode

The profile UUID in your ExportOptions is always current, because it came from the archive itself. Renew the cert, re-download the profile, and nothing breaks.

GitHub Actions Signing

For CI, the certificate lives in a secret as a base64-encoded .p12. The workflow decodes it into a temporary keychain:

security create-keychain -p "$KEYCHAIN_PASS" build.keychain
security import /tmp/cert.p12 -k build.keychain -P "$P12_PASSWORD" \
  -T /usr/bin/codesign
security set-key-partition-list -S apple-tool:,apple: -s \
  -k "$KEYCHAIN_PASS" build.keychain
Enter fullscreen mode Exit fullscreen mode

The -T /usr/bin/codesign flag is critical — without it, the keychain will prompt for a password interactively mid-build, which hangs CI forever. The set-key-partition-list step is what makes it work without prompts.

The Full Flow 

workflow_dispatch
  → checkout (full depth for commit count)
  → import cert into ephemeral keychain
  → write App Store Connect API key
  → ./scripts/release.sh
      → xcodebuild archive
      → extract profile UUID from archive
      → inject UUID into ExportOptions
      → xcodebuild -exportArchive
      → xcrun altool --upload-app
Enter fullscreen mode Exit fullscreen mode

About 8-12 minutes wall clock on a macos-26 runner. No Ruby, no gems, no Fastlane plugins.

When Fastlane Still Makes Sense

If you're managing multiple targets, schemes, environments, or a team with custom lanes — Fastlane earns its complexity. But for a single-target indie app? Raw xcodebuild is readable, debuggable, and requires no maintenance beyond "Xcode updated, did the flags change?"

The full script is about 70 lines of bash. That's the whole pipeline.

Top comments (0)