TestFlight: what is it, beta testing and working with builds

What is TestFlight

TestFlight is the legitimate and only official way to distribute iOS applications for testing without publishing in the App Store. The service was launched by Apple in 2014 after acquiring the company of the same name. Before TestFlight, developers used Ad Hoc distribution with a limit of 100 devices per season — TestFlight removed this limitation and simplified the process to a few clicks.

Why You Need TestFlight

iOS has a strict security policy: an application can only be installed on a device through the App Store or using special certificates. TestFlight solves the problem of beta testing by acting as a proxy between the developer and the tester: Apple checks the build for basic requirements, after which testers receive the application through the TestFlight app from the App Store, which does not require trusting unsigned files.

TestFlight vs Ad Hoc vs Enterprise

There are three ways to distribute iOS applications outside the App Store: Ad Hoc (limit of 100 devices, requires the UDID of each device), Enterprise (in-house distribution without limits, requires an Apple Enterprise certificate for $299/year) and TestFlight (up to 10,000 testers, free, does not require collecting UDIDs). TestFlight is the optimal choice for beta testing, Ad Hoc is suitable for device-specific tests, and Enterprise is for corporate applications.

How TestFlight Works

The process of publishing a build through TestFlight consists of five steps: building in Xcode, uploading to App Store Connect through Archive Organizer, Apple processing, inviting testers, and installing the app through the TestFlight app. Each step takes from a few minutes to an hour depending on the complexity of the project.

Apple’s Build Requirements

The build must be created with a distribution certificate and a valid provisioning profile. Apple checks: certificate validity, bundle identifier match, absence of private APIs, correct icons (1024×1024), and the presence of an App Store icon. If the build does not pass verification, TestFlight shows an error with a description of the problem.

Build Processing

After uploading, the build goes through Apple’s automated verification: static binary code analysis, digital signature verification, scanning for private API usage, and malware. Processing takes from 15 minutes to 2 hours for the first build and usually 15–30 minutes for subsequent ones. The processing status is displayed in Activity in App Store Connect.

// TestFlight Setup in Swift AppDelegate
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Check: is the app installed via TestFlight
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Beta version via TestFlight")
        }
        return true
    }
}

Internal and External Testers

TestFlight divides testers into two groups: Internal Testers and External Testers. The difference is in the number of participants, access to builds, and the need for Apple review. Choosing the right group speeds up the testing process and complies with App Store policies.

Internal Testers

Up to 100 participants from the Apple Developer Program team. To invite an internal tester, simply add their Apple ID in App Store Connect — they immediately get access to all builds. No Apple review is required. Ideal for daily smoke testing and early-stage feature verification.

External Testers

Up to 10,000 participants who are not part of the development team. The first build for external testers goes through a basic Apple review (usually 1–2 days). Subsequent builds with changes that do not affect core functionality may pass without a repeat review. External testers are invited via email or a public link.

How to Upload a Build to TestFlight

Uploading a build to TestFlight is done through Xcode, Application Loader, or the command line using xcrun. The most common method is through Xcode Archive Organizer after creating a project archive. An alternative method is automation through Fastlane for CI/CD Pipeline.

Manual Upload via Xcode

Build an archive (Product → Archive), open Organizer, select the archive and click Distribute App. Select TestFlight as the distribution method, specify the certificate and provisioning profile. Xcode will upload the build to App Store Connect, where it will appear after processing. The entire process takes 10–20 minutes for the first upload.

Automation via Fastlane

Fastlane is the most popular tool for automating build uploads to TestFlight. The command fastlane pilot uploads the build and manages testers without opening Xcode. Integrating Fastlane with a CI/CD server allows publishing builds to TestFlight automatically after passing all tests.

# Fastfile — uploading a build to TestFlight
default_platform(:ios)

lane :beta do
    # Getting certificates via match
    match(type: "appstore")

    # Build and signing
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # Upload to TestFlight
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot automatically uploads the IPA to App Store Connect, waits for processing (if skip_waiting_for_build = false) and assigns the build to selected tester groups. The command distribute_external: true immediately sends the build to external testers after processing.

Upload via Command Line

Without Fastlane, you can use xcrun: xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD. altool is supported by Apple for CI environments and does not require a graphical interface. The password is passed through keychain or an app-specific password — do not use plain-text passwords.

Feedback Collection and Diagnostics in TestFlight

TestFlight provides several feedback mechanisms: a built-in feedback form, automatic crash log collection, usage metrics, and screenshots. The team gets all data in App Store Connect without needing to integrate third-party SDKs for beta testing.

Built-in Feedback Form

The tester opens the TestFlight app, selects your build, and clicks Send Feedback. The form allows sending a text review, attaching a screenshot, and specifying severity. All feedback is collected in App Store Connect under TestFlight → Feedback. The developer can reply to the feedback, and the tester will receive a notification in the TestFlight app.

Crash Logs and Diagnostics

When an app crashes, TestFlight automatically collects a crash report: call stack, OS version, device model, and crash time. Crash logs are available in Xcode Organizer (Crashes) and App Store Connect (TestFlight → Crashes). To get symbolicated crash logs, you need to upload dSYM files with the build or separately through Xcode.

Usage Monitoring

TestFlight shows metrics: number of installs, active testers, sessions, and crashes. Analytics are updated daily and help assess tester engagement. If no tester has opened the app in a week, it is worth reconsidering communication with the group or the build quality.

From TestFlight to App Store Publication

TestFlight is an integral part of the App Store publication process. The same build that went through beta testing via TestFlight can be submitted for Apple review without rebuilding — just click a button in App Store Connect. This eliminates the risk that the production build differs from the tested one.

Submit to App Review

In App Store Connect, select the build that passed testing and click Submit for Review. Apple uses the same build from TestFlight — no re-upload is required. Review time is usually 1–3 days. If the build is rejected, fix the issues, upload a new build to TestFlight, and repeat the process.

Final Build Before Release

It is recommended to wait 24–48 hours after the final testing round in TestFlight before submitting for review. This time allows testers to find critical bugs that might pass automated tests. Release candidate (RC) build in TestFlight is a standard practice for mature iOS teams.

What to Do After Publication

TestFlight builds automatically become unavailable for new installations after the release version goes live in the App Store. Testers who already installed the beta version can continue using it for 30 days after the release publication, after which the app stops opening. Make sure testers update to the App Store version.