Manual archive-and-upload gets old fast. Here's how to automate building, signing, and pushing native iOS builds to TestFlight using Xcode Cloud or fastlane in a CI/CD pipeline.
Manually archiving and uploading every build is slow and error-prone. Each manual step is a chance to pick the wrong signing identity, forget to bump the build number, or skip a test.
Automation turns delivery into a repeatable pipeline. A commit or a tag triggers a build, the binary is signed, tests run, and a fresh build lands in TestFlight without anyone touching Xcode by hand.
This matters more as your team grows and your release cadence increases. The faster you want to iterate with testers, the more a manual process becomes the bottleneck.
Two mainstream paths exist on Apple platforms: Xcode Cloud, Apple's own CI service integrated with App Store Connect, and fastlane, the long-standing open-source automation toolkit. Both compile a real native binary, which is still the non-negotiable foundation of any TestFlight delivery.
You need an Apple Developer Program membership and an app record already created in App Store Connect. Automation pushes builds into that record; it does not create your developer relationship for you.
You need a project that archives cleanly. If it fails to build locally, it will fail in CI too, so get a clean manual archive working first.
You need your signing strategy decided. Automatic signing can work, but many teams prefer managed certificates and profiles so CI machines have predictable credentials.
And you still need a native target. CI does not change the fundamental rule that TestFlight only accepts compiled, signed Apple binaries, so a web or AI-builder export must already be a real native iOS app before automation can help.
Xcode Cloud is Apple's continuous integration and delivery service, configured from within Xcode and tied directly to App Store Connect. Because it is first-party, signing and TestFlight delivery are tightly integrated.
In Xcode, you start by creating a workflow for your project. You connect your source repository and define when builds should run.
A workflow defines triggers, such as a push to a branch or a new tag, and actions, such as building, testing, and archiving. You can configure a workflow to deliver successful archives straight to TestFlight.
The big advantage is that Apple manages the build environment and much of the signing complexity. You focus on what to build and when, and Xcode Cloud handles the machinery of getting it into TestFlight.
fastlane is an open-source toolkit that automates iOS build and release tasks from the command line. It runs anywhere you can run a Mac build agent, including most CI providers.
Install fastlane and run its init in your project directory to create a Fastfile. This file is where you define lanes, which are named sequences of automation steps.
The relevant action for TestFlight is pilot, commonly invoked through the upload_to_testflight lane action. A typical lane builds the app with gym, then uploads the resulting binary.
fastlane also offers match for managing signing certificates and profiles across machines, which keeps CI agents in sync. The result is a single command, or a single CI trigger, that builds, signs, and delivers your build to TestFlight.
Start by defining a lane in your Fastfile dedicated to beta delivery. Conventionally this lane is named beta.
Inside the lane, call the build action (gym) to produce a signed archive. Make sure the export options and signing identity match your distribution setup.
Next, call upload_to_testflight to push the resulting binary to App Store Connect. You can pass parameters to control whether external testers are notified and which group receives the build.
Finally, wire this lane into your CI provider so a push or tag runs it automatically. Use an App Store Connect API key for authentication rather than a password, because API-key auth is more reliable and secure for unattended automation.
Automation makes versioning discipline essential. App Store Connect rejects a build whose number was already processed for that version, so every automated build must carry a unique build number.
A common pattern is to derive the build number from your CI run number or a timestamp. fastlane offers helpers like increment_build_number to manage this automatically.
Keep your marketing version, the user-facing version string, separate from the build number. The marketing version changes when you decide; the build number changes on every upload.
Getting this right eliminates one of the most common automation failures, the silent rejected upload caused by a duplicate build number that nobody noticed until testers asked where the new build was.
Automation means your pipeline holds credentials that can sign and ship builds, so handling them safely matters. Never commit signing certificates, private keys, or API keys into your repository.
For App Store Connect access, generate an API key in the Users and Access area and store it as an encrypted secret in your CI provider. Both Xcode Cloud and fastlane can authenticate with that key instead of an interactive Apple ID login.
For signing, fastlane's match stores certificates and profiles in an encrypted, access-controlled location and syncs them to build agents on demand. This keeps every machine consistent without scattering raw key material around.
Xcode Cloud takes a different approach, managing much of the signing for you within Apple's environment, which reduces the number of secrets you handle directly.
Whichever path you choose, treat the principle the same way: secrets live in your CI's secret store, never in source control, and they are rotated when they expire or when someone leaves the team.
After your first automated upload, confirm the build appears in the TestFlight tab and finishes processing. Automation does not skip the processing wait that manual uploads have.
Add a test step before delivery. Running your unit and UI tests in CI means a broken build never reaches testers in the first place.
Monitor for signing expiration. Certificates and profiles expire, and an unattended pipeline will start failing the moment they do, so rotate them proactively with match or Xcode Cloud's managed signing.
Remember the 90-day expiration on builds. An automated cadence naturally keeps fresh builds flowing, but make sure your pipeline actually runs often enough that testers never end up stranded on an expired build.
Xcode Cloud is Apple's first-party CI with tight App Store Connect integration and managed signing, which suits teams that want minimal setup. fastlane is open-source, runs on many CI providers, and offers fine-grained control. Both compile a native binary and deliver to TestFlight.
fastlane uses pilot, commonly invoked through the upload_to_testflight lane action, to push a signed binary to App Store Connect for TestFlight distribution.
Use an App Store Connect API key rather than an Apple ID password. API-key authentication is more secure and reliable for unattended automation and avoids interactive two-factor prompts.
The most common cause is a duplicate build number. App Store Connect rejects a build whose number was already processed for that version, so automation must assign a unique build number for every upload, often derived from a CI run number or timestamp.
No. Even with automation, App Store Connect still processes each uploaded binary before it becomes available in TestFlight. Automation speeds up the build and upload steps, not Apple's processing time.