A practical, step-by-step guide to going from a compiled Xcode build to a live TestFlight beta, covering archiving, uploading, tester groups, and your first invites.
Before TestFlight enters the picture, you need a few prerequisites in place. The most important is an active Apple Developer Program membership, because that membership unlocks App Store Connect and distribution signing.
You also need Xcode installed on a Mac, since compiling and signing a native iOS binary is something only Xcode (or a CI service wrapping it) can do.
Finally, you need an actual app project that builds and runs. TestFlight distributes finished binaries, not source code, so your project must archive successfully before any of this works.
If your app started life in a web or AI builder, this is the moment to confirm you have a real native target. A web export must be rebuilt or wrapped as a native iOS app in Xcode first; there is no way to push raw web code into TestFlight.
Log in to App Store Connect with your developer account. Navigate to the Apps section and create a new app record.
You will be asked for a name, primary language, bundle ID, and SKU. The bundle ID must match the identifier in your Xcode project exactly, or the upload will fail to associate with this record.
If your bundle ID does not appear in the dropdown, you may need to register it first in the Certificates, Identifiers and Profiles section of the developer portal.
This app record is the home for everything that follows. TestFlight builds, metadata, and tester groups all live under it, so getting it created correctly is the foundation for the rest of the process.
Open your project in Xcode and select your real device or the generic "Any iOS Device" build target. You cannot archive for distribution from a simulator destination.
In your target's Signing and Capabilities tab, make sure automatic signing is enabled or that you have the correct distribution provisioning profile selected. Confirm the team matches your developer account.
When signing looks correct, choose Product, then Archive from the menu. Xcode will compile a release build and place it in the Organizer window.
Archiving is where a lot of first-time issues surface, such as missing capabilities or an expired certificate. If the archive fails, fix the signing problem before moving on, because TestFlight cannot accept an unsigned or mis-signed binary.
With the archive selected in the Organizer, click Distribute App. Choose the App Store Connect option and follow the prompts to upload.
Xcode will validate the archive, re-sign it for distribution if needed, and transmit it to App Store Connect. This can take several minutes depending on app size and your connection.
After the upload completes, the build does not appear instantly in TestFlight. App Store Connect processes the binary first, which can take anywhere from a few minutes to longer during busy periods.
If you prefer automation, fastlane or Xcode Cloud can perform this upload step for you. Either way, the underlying flow is the same: a signed archive goes up, gets processed, and becomes a TestFlight build.
Once the build finishes processing, open the TestFlight tab of your app in App Store Connect. Your processed build should now be listed.
Start with internal testers. These are people you add to your App Store Connect team with the appropriate role. Internal testers can receive builds quickly without waiting on a beta review.
Create an internal tester group if you want, then assign the build to it. Each tester receives an invitation and installs your build through the TestFlight app on their device.
Internal testing is the fastest feedback loop you have, so use it to catch obvious breakage before you expose the build to a wider external audience.
External testers are anyone outside your team. To distribute to them, create one or more external tester groups in the TestFlight tab.
You will need to provide test information such as a description of what to test and a contact email. Before the first external build goes out, Apple typically runs a Beta App Review, so expect a short wait for approval.
You can add external testers by entering their emails, or you can enable a public link. The public link lets anyone install the beta, up to the 10,000 external tester limit.
Once the build is approved and assigned, external testers get the invite and install just like internal ones. The public link is especially handy for recruiting testers from social media or a community without managing individual emails.
After testers install your build, feedback starts flowing back into App Store Connect. Testers can submit screenshots with annotations and written comments directly from the TestFlight app.
Crash reports are also collected, giving you signal on stability across real devices and OS versions you may not own yourself.
Write clear release notes for each build so testers know what changed and what to focus on. Good notes dramatically improve the quality of feedback you get back.
Remember that each build expires 90 days after upload. Plan to upload fresh builds regularly so testers are never stuck on a stale, expired version, and so your beta program keeps moving forward.
It helps to be clear on the two testing tracks before you scale up. Internal testing is for people on your App Store Connect team, and it is built for speed.
Internal builds become available to those testers without a Beta App Review, so you get feedback almost as soon as processing finishes. This makes internal testing the right home for quick smoke tests and sanity checks.
External testing is for everyone outside your team. It is where you reach real-world users, but it adds the Beta App Review gate for the first build.
Because of that gate, plan to lead with internal testing and only promote a build to external testers once it is stable. That sequencing saves you from burning review cycles on builds that still have obvious problems.
Knowing which track a given build belongs in keeps your beta program organized and your feedback meaningful.
Keep your internal and external groups distinct in purpose. Use internal testing for fast smoke tests and external testing for broader, real-world coverage.
Automate the upload step as early as you can. Wiring up Xcode Cloud or fastlane removes a repetitive manual chore and reduces the chance of a signing mistake slipping through.
Version and build numbers matter. Increment your build number for every upload, because App Store Connect rejects a build that reuses a number already processed for that version.
Finally, treat TestFlight as the last mile of a native pipeline. Everything upstream, the compiling, signing, and archiving, still happens in Xcode, and TestFlight only takes over once you have a valid native binary in hand.
After Xcode finishes uploading, App Store Connect must process the binary. This usually takes a few minutes but can be longer during busy periods. The build appears in the TestFlight tab once processing completes.
No. Internal testers, who are members of your App Store Connect team, can generally receive builds without a beta review. External testers typically require a Beta App Review before the first public build is distributed.
You need Xcode somewhere in the pipeline to compile and sign a native binary. You can automate the upload itself with tools like fastlane or Xcode Cloud, but those still rely on Xcode's build toolchain under the hood.
An email invite targets specific known testers, while a public link lets anyone who has the URL install your beta, up to the 10,000 external tester limit. Public links are ideal for open recruitment from social media or communities.
App Store Connect rejects a build that reuses a build number already processed for that version. Increment the build number for every new upload to avoid this.