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)}"
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"
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"
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
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
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.
SOCIAL SHARE CARD GENERATOR