TestFlight is Apple’s free beta-testing service. Every indie iOS app should run a TestFlight beta before submitting to the App Store — not because Apple requires it, but because it catches the signing, in-app-purchase, and entitlement bugs that get apps rejected, on real devices, before an App Review reviewer ever opens your binary.
TL;DR
- TestFlight is free and built into App Store Connect. Two tracks: up to 100 internal testers (instant, no review) and up to 10,000 external testers (the first build of each version clears Beta App Review first).
- Each build is testable for 90 days, then it expires and you must ship a new one.
- Upload from Xcode (Archive → Distribute) or the command line.
xcrun altoolstill uploads, but Apple now points indie teams at Transporter + an App Store Connect API key instead of an Apple ID password. - The feedback you get is only as good as your “What to Test” note. Write 3-5 specific things to check, not “test the new version”.
- Ship a fresh build every 2-5 days during an active beta. Stagnant betas die — testers forget the app exists.
What TestFlight actually buys you
For indie developers the value is twofold. First, it forces you to ship a real distribution build through Apple’s tooling, which surfaces IAP, code-signing, and provisioning bugs that never show up in a debug build on your own phone. Second, it puts the app on other people’s devices under real conditions — different iPhone models, older iOS versions, spotty networks — before the reviewer (and your paying users) see it.
What it is not: a launch or marketing channel. TestFlight users are testers, not customers. They will not convert to App Store downloads at launch, and the install link stops working once the build expires.
TestFlight limits at a glance (June 2026)
| Thing | Limit / behavior |
|---|---|
| Internal testers | Up to 100 App Store Connect users (roles: Account Holder, Admin, App Manager, Developer, Marketing) |
| External testers | Up to 10,000 per app |
| Beta App Review | Required for the first build of each version on external; internal needs none |
| Review turnaround | Typically under 24h, often a few hours; Apple gives no SLA |
| Build lifetime | 90 days from upload, then it expires |
| Builds per app | One “active” build per group, but testers can pick from recent builds |
| Public Link cap | Same 10,000 ceiling; once full you can only disable the whole group |
| Cost | Free with an Apple Developer Program membership ($99/yr as of June 2026) |
Source: Apple’s TestFlight overview in App Store Connect Help.
When you’re ready to start
- You have a working build that compiles and runs on at least your own device.
- You are within 1-3 weeks of submitting to the App Store.
- You have at least 3-5 people who would actually use the app.
- You have some way to collect feedback (email, Discord, a form — anything).
Step by step
1. Archive and upload
In Xcode:
1. Set the device target: Any iOS Device (arm64) — not a simulator
2. Product → Archive (5-15 min)
3. Organizer opens → "Distribute App" → "App Store Connect" → "Upload"
4. Signing: Automatically manage signing (unless your org uses manual certs)
5. Wait for upload (10-30 min, depends on size and bandwidth)Command-line alternative (skip the Xcode UI). Note that altool with an Apple ID password is the old path; Apple now recommends the Transporter tool with an App Store Connect API key (a .p8 file you generate under Users and Access → Integrations). Both still upload as of June 2026:
# Archive
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp \
-configuration Release -archivePath build/MyApp.xcarchive archive
# Export ipa
xcodebuild -exportArchive -archivePath build/MyApp.xcarchive \
-exportOptionsPlist ExportOptions.plist -exportPath build/
# Upload with an API key (recommended)
xcrun altool --upload-app -f build/MyApp.ipa -t ios \
--apiKey ABC123XYZ --apiIssuer 11111111-2222-3333-4444-555555555555You must upload with Xcode 14 or later as of 2026. Common upload failures: bundle ID mismatch with App Store Connect, missing push-notification entitlement, or an Info.plist missing a required usage-description key such as NSLocationWhenInUseUsageDescription.
2. Wait for processing
Watch App Store Connect → TestFlight → Builds:
Uploading in progress
Processing Apple processes (5-30 min)
Ready to Test ← ready
Invalid Binary ← failed, check the email Apple sent
Missing Compliance ← encryption answer missing; fill it in on the build detailFor “Missing Compliance”, most apps pick “No, encryption used is exempt” — plain HTTPS counts as exempt. You can also set ITSAppUsesNonExemptEncryption to false in Info.plist to skip the prompt on every build.
3. Configure Internal Testing (up to 100, no review)
App Store Connect → TestFlight → Internal Testing → "+"
- Group Name: Internal QA
- Test Information:
- Beta App Description: focus of this test
- Email: your feedback inbox
- Add Testers: pick Account Holder + Developer-role members
- Enable for Build: select your build → SaveInvites land in their TestFlight app immediately. Note: testers using free Apple IDs can’t run sandbox IAP purchases — your team needs sandbox tester accounts (created under Users and Access → Sandbox).
4. Configure External Testing (up to 10,000)
The first new build of a version goes through Beta App Review (typically under 24h, often a few hours):
App Store Connect → TestFlight → External Testing → "+"
- Group Name: Public Beta (or a specific cohort like "Power Users")
- Add Testers: type emails, CSV import, or enable Public Link
- Build to test: select build
- Submit for Beta App Review:
- Beta App Description: ≤4000 chars (can reuse your App Store description)
- What to Test: focus of this version (see step 5)
- Demo account: if login is required
- Notes: anything the reviewer needs to know5. Write a real “What to Test”
Not “test everything” — 3-5 specific items:
Bad: "Please test the new version"
Good:
Focus this build:
1. New onboarding (first 60s): can a fresh user finish setup with no guidance?
2. iPad landscape: does the 21-day calendar still display fully after rotating?
3. Family Sharing: when shared with family members, do push notifications arrive within 30s?
4. Memory: after 30 minutes of continuous use, does the app slow down or get killed?
Do NOT test:
- Settings page (unchanged from the previous build)
- Detailed charts (known bug, fixed in v1.1.1)6. Use Public Link sparingly
Enable it under the External Testing group detail → “Enable Public Link”.
Upside: anyone with the link can install (up to 10,000)
Downside:
- Once full, you can only disable the entire group
- Can be scraped by bots that fill the slots
- No identity → low-quality feedback
Recommended: private invites + Discord-collected emails → manually add to External Testers7. Set up feedback channels
Run one of each, each pointed at a different scenario:
TestFlight built-in feedback:
Tester screenshots + "Send to Developer" — includes device / OS / build metadata
View at App Store Connect → TestFlight → Feedback
Email:
Put beta@yourdomain.com in "What to Test"; lets testers paste stack traces inline
Discord / Slack channel:
A long-term beta community; @everyone on each new build
Crash reporting:
Wire up Sentry or Crashlytics for TestFlight builds before the beta starts
View at App Store Connect → TestFlight → Crashes (Sentry's realtime view is usually better)8. Keep a 2-5 day cadence
Stagnant betas die — testers forget the app exists.
Suggested cadence:
D0 First build
D2 Patch obvious bugs, ship v1.0.1
D5 Small feature iteration + second wave of fixes, ship v1.0.2
D7 Full sweep, prepare for App ReviewEach new build push triggers a TestFlight notification to all testers with the What’s New text.
9. Run one final build before App Review
Use the exact metadata you plan to submit (screenshots, keywords, description, privacy answers) and push it through External:
Purpose:
- Have 5-10 real users live with the near-final experience for 24h
- Catch last-mile issues: icon rendering on certain devices, IAP sandbox-to-production
transition, push-token registration failing in the Production environment
Only then promote the same build to App Review via "Add for Review".Common pitfalls
- Treating TestFlight as a launch channel. Testers are not customers, and they will not convert at launch.
- Adding “test123” placeholder accounts. Fake users produce useless feedback.
- Letting builds expire. Builds expire 90 days after upload; if your beta runs longer, ship a new build.
- Not testing IAP in the sandbox. TestFlight uses sandbox StoreKit, not production — purchases must be made as a sandbox user.
- Skipping the tester scope in your Beta App Review notes. Apple does read them.
- Adding crash logging at the last minute. Wire up Sentry or Crashlytics before the beta starts, or your crash reports are useless.
Who this is for
Any indie iOS developer about to launch their first app, or shipping a major version update.
When to skip it
Apps so simple a 30-minute self-test catches everything — though those are rarer than you’d think.
FAQ
- How many testers should I have? 5-15 active testers is usually enough for an indie app. More testers means more feedback to triage, not better feedback.
- How long should a beta run? 1-3 weeks for most indie apps. Under a week is too short to surface non-obvious bugs; over a month and tester motivation drops.
- Does TestFlight cost anything? No. It’s included with the Apple Developer Program ($99/year as of June 2026). There is no per-tester fee.
- Will the TestFlight build conflict with the App Store version? No. TestFlight installs alongside the App Store version with a slightly different icon badge; they do not overwrite each other.
- How long does Beta App Review take? Usually under 24 hours, often a few hours, and only for the first build of a version on an external group. Apple publishes no SLA, so budget a day before a planned external push.
- Can testers leave App Store reviews? Not from the TestFlight build. They’d need to install the App Store version after launch and review there.
Related
- What an Indie Developer Should Prepare Before Launching on the App Store
- In-App Purchases via RevenueCat — a 30-Minute Intro
- After Launch — How to Iterate on Your App Store App Without Panic
Tags: #Indie dev #App Store #TestFlight #App launch #Getting started