TestFlight Introduction
TestFlight is Apple’s official beta testing distribution tool, built into App Store Connect at no extra cost. It supports iOS / iPadOS / macOS / tvOS / watchOS.
What TestFlight Is
TestFlight lets you distribute builds to real users for testing before release. It solves the core problems of:
- Real-device verification: push, camera, location, performance, and review paths that the simulator can’t cover.
- Small-scale staged rollout: let a small group try before everyone, lowering the cost of finding problems.
- Collecting feedback: testers can give feedback directly in the TestFlight app, and crashes upload automatically.
Compared to Ad Hoc, TestFlight doesn’t require registering device UDIDs — testers just install the TestFlight app and accept an invite, making management far easier.
Two Testing Methods
| Aspect | Internal Testing | External Testing |
|---|---|---|
| Audience | Team members (dev, QA, product) | External real users / customers |
| Limit | 100 members | 10,000 testers |
| Requires review | No (Beta App Review) | Yes (first build of the version) |
| Invitation | Add member emails | Email invite / public link |
| Testers must be team members | Yes | No |
| Feedback entry | In TestFlight app | Same |
”Internal testing needs no review” only means it’s fast — but internal testers must be team members (Admin / App Manager / Developer roles) and it’s limited to 100 people. For external users you must use external testing.
Basic Workflow
A typical TestFlight test cycle:
- Build & upload: upload a build signed with a distribution certificate via Xcode, Transporter, or CI (fastlane).
- Wait for processing: the build shows “Processing” in App Store Connect, usually minutes to tens of minutes.
- Create a test group: create internal/external groups and attach the build.
- Add testers: internal adds team members; external adds emails or enables the public link.
- Install & test: testers install the TestFlight app, accept the invite, and download the build.
- Collect feedback: testers report issues in-app or via crash reports.
- Fix & iterate: fix issues, upload a new build, repeat.
- Submit: after testing passes, submit the final build to App Store review.
Build Expiration
TestFlight builds expire 90 days after upload. If you don’t keep uploading new builds within 90 days, old builds become invalid and testers can no longer install them. This is a hard constraint that enforces a steady iteration cadence.
Key Concepts
| Concept | Description |
|---|---|
| Build | A compiled artifact with a unique build number |
| Test Group | A set of testers, attachable to specific builds |
| Beta App Review | The review step for external testing, different from full review |
| Export Compliance | Export compliance declaration, involving encryption |
| TestFlight App | The tester-side install/feedback tool (free on the App Store) |
FAQ
- TestFlight vs on-device debugging (development mode)? Development mode requires adding device UDIDs to profiles, for fast debugging; TestFlight uses distribution signing for near-production builds and doesn’t require UDID management.
- Do testers need a developer account? No. External testers only need an Apple ID.
- Is the external build the same one submitted for review? Not necessarily. Usually one build is used for external testing, and after passing you submit for full review (can be the same build).
- Build stuck on Processing? Usually just wait; if it exceeds several hours, check distribution signing, export compliance, and upload errors.
Team tip: make “one round of internal + one round of external testing before submission” a mandatory release gate. It dramatically reduces App Store rejections and production incidents.