TestFlight beta testing: the complete guide

TestFlight is Apple's beta distribution service and the standard way to get iOS, iPadOS, macOS, watchOS, tvOS and visionOS builds to testers before the App Store. This guide walks through internal and external testers, groups and public links, Beta App Review, build expiry, how feedback and crash reports arrive, and how to pair TestFlight with an AI beta tester so your human testers meet a stable build.

Who it’s for

  • Developers setting up TestFlight for the first time
  • Teams moving from internal testing to an external beta
  • Product managers who need to understand limits and review timing
  • Indie developers running a long public beta across many builds

Updated 2026-10-25.

What TestFlight is

TestFlight is Apple's service for distributing pre-release builds to testers. You upload a build to App Store Connect, add testers, and they install it through the free TestFlight app. Builds behave like App Store installs, including in-app purchases in the sandbox, push notifications and background behavior, which is why it is the standard for iOS beta testing. It is also the only route Apple offers for beta distribution to the public outside of enterprise programs.

Internal vs external testers

  • Internal testers are up to 100 members of your App Store Connect team with an assigned role. They can install any build as soon as it finishes processing, no review required. Use them for your own team and for daily builds.
  • External testers are anyone else, up to 10,000 per app, invited by email or through a public link. The first build you send to external testers must pass Beta App Review. External testers do not need an App Store Connect account.

You organize external testers into groups. Each group can receive different builds, so a typical setup is a small "trusted" group that gets every build and a larger "public" group that gets builds once the trusted group has stopped finding blockers.

Public links

A public link is created per external group. Anyone with the link can join until the cap you set is reached, and you can disable the link at any time. Public links are how most teams fill a beta: one link in a newsletter, a community post or your website replaces manual email invites. Testers who join by public link appear in the group like any other and can be removed.

Beta App Review and build expiry

  • The first build of a version sent to external testers goes through Beta App Review, a lighter version of App Store review that checks for crashes, obvious guideline problems and a working demo account if sign-in is required. Plan a day or more for it; later builds of the same version typically clear faster.
  • Every build expires 90 days after upload, for internal and external testers alike. When it expires, testers see a message that the beta has ended. For a beta longer than three months, ship new builds on a schedule.
  • You can set a maximum of several builds active at once, and you can expire a build manually to force testers onto the newest one.

Check Apple's current TestFlight documentation for exact numbers; limits and review practices change.

What testers see and how feedback arrives

  • Testers install the TestFlight app, accept the invite or tap the public link, and install your build. They see your What to Test notes for each build, so write them: what changed, what to try, what you already know is broken.
  • Testers can send feedback by taking a screenshot (a "Send Beta Feedback" option appears) or from the TestFlight app. Feedback includes the screenshot, their comments, device model, iOS version and build.
  • Crashes in TestFlight builds produce crash reports that appear in App Store Connect, often with the tester's comment if they chose to add one. Symbolicate them with your dSYMs to read them.
  • A tester can only have one TestFlight build of your app installed at a time; installing the beta replaces the App Store version on their device.

Setting up a TestFlight beta, step by step

  1. Archive the app in Xcode with a build number higher than the last one and upload it to App Store Connect.
  2. Complete the Test Information section: beta app description, feedback email, privacy policy URL and, if sign-in is required, a demo account for Beta App Review.
  3. Add internal testers and run the first pass on the processed build.
  4. Create an external group, write What to Test notes and add the build. Submit for Beta App Review.
  5. Invite a small trusted group by email first. After the first round of fixes, create a public link for a larger group.
  6. Review feedback and crash reports at a fixed rhythm, for example twice a week, and reply to testers who report.
  7. Ship fixed builds to the same groups, keeping the 90-day expiry in mind.
  8. When serious reports stop, submit the build for App Store review. The same build you tested can be submitted; no new upload is needed.

TestFlight checklist

  • Build number increments on every upload.
  • What to Test notes written for each build.
  • Demo account with realistic data for Beta App Review and testers.
  • Privacy policy and support URLs live and correct.
  • In-app purchases configured so sandbox purchases work in TestFlight; no real charges happen in TestFlight builds.
  • Push notification entitlement uses the production environment (TestFlight uses production APNs).
  • Crash symbols (dSYMs) uploaded so crash reports are readable.
  • Expiry dates noted; next build scheduled before the current one expires.

Example What to Test notes

Build 2.4.0 (118)

What changed
- New onboarding (3 screens instead of 5)
- Sign in with Apple added
- Fixed the crash when opening a shared link while offline

Please try
1. Delete and reinstall, then go through onboarding on your first launch
2. Sign in with Apple, then sign out and back in with email
3. Open a shared link from Messages with Wi-Fi off

Known issues
- Dark mode colors on the Stats tab are still wrong; no need to report

Common TestFlight mistakes

  • Sending the first build to external testers before internal testers have caught launch crashes, then waiting on Beta App Review for a fix.
  • Letting the only build expire so the whole group sees "beta has ended".
  • Empty What to Test notes, which turn testers into installers.
  • No demo account in Test Information, so Beta App Review stalls.
  • Testing in-app purchases with a real Apple ID instead of a sandbox tester account.
  • Assuming TestFlight feedback is representative of all users: testers skew toward the technically curious.

TestFlight limits at a glance

  • 100 internal testers, 10,000 external testers per app.
  • 90 days per build.
  • Beta App Review for the first external build of each version.
  • Groups and public links to stage who gets what.

Verify current figures with Apple before publishing a plan that depends on them.

Combining TestFlight with an AI beta tester

TestFlight distributes the build; it does not test it. An AI beta tester like betatest.ing does the methodical pass that human testers skip: export the same build as an ad-hoc or development .ipa, upload it, and it installs it on a real iPhone or iOS simulator, goes through every screen and core flow, denies permissions, checks safe areas, swipe back, keyboard overlap, dark mode and Dynamic Type, and files bug reports with steps to reproduce, severity, annotated screenshots and screen recordings. Its Store readiness checks cover the things Beta App Review and later App Store review look for: privacy policy link, demo account, Sign in with Apple, account deletion and placeholder content.

It cannot install from TestFlight, so keep TestFlight for people. Run the AI pass on each build before it goes to external testers and before you submit to the App Store, and re-run it on a schedule as a regression test.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Beta test my iOS app (the uploaded .ipa, exported for ad-hoc or development distribution from the same build I am sending to TestFlight) before external testers get it. It is [WHAT THE APP DOES AND WHO IT IS FOR]. Install it on an iPhone, go through first launch, onboarding and every permission prompt (deny one and check the app explains what to do), sign in with the saved test login, and use each main screen and flow. Pay special attention to what changed in this build: [WHAT CHANGED IN THIS BUILD]. Check safe areas around the notch, Dynamic Island and home indicator, swipe back on every pushed screen, sheet dismissal, keyboard overlap, dark mode and the largest text size. Check the privacy policy and support links open. Do not make any purchases. Log each bug with steps to reproduce and an annotated screenshot, record any flow that breaks, and end with a report that scores stability, navigation, layout and App Store readiness, with the fixes to ship before this build goes to external testers.

Fill in your details

Here, or later in the chat with your tester.

  • [WHAT THE APP DOES AND WHO IT IS FOR] One sentence about the app and its users
  • [WHAT CHANGED IN THIS BUILD] The same list you put in the What to Test notes

What the AI beta tester checks

  • Install of the .ipa and a clean first launch
  • Onboarding, sign-in and permission prompts, including deny
  • Everything listed as changed in this build
  • Every main screen and core flow
  • Safe areas, swipe back, sheets and keyboard overlap
  • Dark mode and largest Dynamic Type size
  • Privacy policy and support links
  • Crashes, dead buttons and placeholder content

What you get

  • Bug reports with steps to reproduce, severity and annotated screenshots
  • Screen recordings of flows that crash or break
  • A scored report on stability, navigation, layout and App Store readiness
  • The fixes to ship before the build goes to external TestFlight testers

How to run it with betatest.ing

  1. Add your app as a project in betatest.ing and upload an .ipa exported for ad-hoc or development distribution.
  2. Add the same demo login you give Beta App Review.
  3. Send the task; the tester installs the build on a real iPhone and files findings.
  4. Fix blockers, upload the next build and re-run before each TestFlight external release.

Tips

  • Write What to Test notes for every build; empty notes turn testers into installers.
  • Keep a trusted group that gets every build and a public-link group that gets stable ones.
  • Schedule the next build before the current one hits 90 days.
  • Upload dSYMs so TestFlight crash reports are readable.
  • Use sandbox tester accounts for in-app purchases; TestFlight never charges real money.

TestFlight beta testing: FAQ

What is the difference between internal and external TestFlight testers?

Internal testers are up to 100 members of your App Store Connect team and get builds without review. External testers are anyone else, up to 10,000, invited by email or public link, and the first build for them must pass Beta App Review.

How long does Beta App Review take?

Usually a day or so for the first build of a version, sometimes longer. Later builds of the same version typically clear faster. Provide a demo account in Test Information to avoid delays.

Why does my TestFlight build say the beta has ended?

Builds expire 90 days after upload. Upload a new build and testers can install it; schedule builds so the current one never expires mid-beta.

How do testers send feedback in TestFlight?

By taking a screenshot in the beta app and choosing Send Beta Feedback, or from the TestFlight app itself. Feedback arrives in App Store Connect with device model, iOS version, build and the screenshot.

Where do TestFlight crash reports go?

To App Store Connect under the build's feedback section, with any comment the tester added. Upload dSYMs so the reports are symbolicated and readable.

Do in-app purchases work in TestFlight?

Yes, in the sandbox. Purchases in TestFlight builds are not charged. Use sandbox tester accounts, and test restore purchases on a clean install.

Can an AI beta tester install from TestFlight?

No. Export the same build as an ad-hoc or development .ipa and upload it to betatest.ing; it installs the build on a real iPhone, tests every flow and files bugs with screenshots and recordings. TestFlight stays for your human testers.

Can I submit the TestFlight build to the App Store?

Yes. The build you tested can be attached to an App Store version and submitted for review without a new upload, as long as it has not expired.

Related beta testing guides

  • Find iOS beta testers — TestFlight makes distributing an iOS beta easy; finding people who install it and keep reporting is the hard part. This guide covers how TestFlight public links and limits work, where to recruit iPhone testers, what to offer them, how to keep them engaged across 90-day build cycles, and how an AI beta tester fits in before the first invite goes out.
  • iOS app beta testing — TestFlight is how almost every iOS app gets into beta testers' hands before the App Store. This guide explains how TestFlight testing works, what to check on iPhone that differs from Android, and how to run an AI beta test on a real iPhone from an uploaded .ipa build.
  • App Store rejection reasons — Most App Store rejections are not about taste. They cite a small set of guidelines: the app crashed, a login had no demo account, a purchase bypassed in-app purchase, a social login lacked Sign in with Apple, or there was no way to delete an account. This guide lists the common rejection reasons by guideline number, what reviewers actually check, and a review-readiness task your AI beta tester can run on the build before you press Submit.
  • In-app purchase testing — In-app purchases are the flow you can least afford to ship broken and the one teams test least, because nobody wants to pay real money on every build. This guide covers how the Apple and Google sandboxes work, which subscription states to test, and a task your AI beta tester can run against your paywall without ever completing a real purchase.
  • Mobile app pre-launch checklist — Launching a mobile app means passing two store reviews, surviving real devices and keeping users on day one. This checklist walks through everything to verify before you submit, from builds and beta testers to store policies, in-app purchases, crashes and the listing itself, with links to detailed guides for each step and a full pre-launch task your AI beta tester can run.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in guides