TestFlight external testing checklist: 10 checks

Internal testers (people on your App Store Connect team) get a build as soon as Apple has processed it and export compliance is answered. External testers wait for Beta App Review. When a build sits in TestFlight without reaching external testers, check the items below first.

The list applies to iPhone, iPad and Apple TV apps: they all go through TestFlight the same way. In VibeView, the TestFlight details dialog (Builds → Stores → your app) and the Submit dialog’s Ready to send list show most of these checks in one place, and vibeview testflight info prints the same from the command line.

A few terms come up throughout:

• The Account Holder is the person who enrolled your team in the Apple Developer Program. Only they can accept Apple’s agreements.
• Export compliance is Apple’s question, for every build, about whether the app uses encryption beyond the exempt cases.
• An external group is a TestFlight group of people you invite by email who aren’t on your App Store Connect team. An internal group is people who are.
• Beta App Review is Apple’s check of a build and its test information before external testers can install it.

Commands marked with a CLI version need that version of the VibeView CLI or newer; vibeview --version shows yours.

The checklist at a glance

Items 1, 2, 5, 6 and 8 are setup: you do them once per app (or, for the agreement, whenever Apple updates it), and change them only when something changes. Items 3, 4, 7 and 9 come up with every build. With an export compliance answer saved for the app, item 4 takes care of itself after the first build.

1. An App Store Connect key with the App Manager or Admin role

Why. Apple lets only the Account Holder, Admins and App Managers create external groups and invite testers. VibeView adds builds to your groups and sends them to Beta App Review with your App Store Connect API key, so the key needs one of those roles too.

Where in App Store Connect. Users and Access → Integrations → App Store Connect API, where the Account Holder or an Admin creates team keys.

In VibeView. Store the key once under Builds → Stores, or with vibeview credentials asc-key add. Test connection (or vibeview credentials asc-key test <name>, CLI 0.56.0 or later) asks Apple with that key without changing anything. If the role is too low, the build’s card says The key can’t manage TestFlight testers: create a key with the App Manager or Admin role, delete the old key in Builds → Stores and add the new one under the same name.

2. Apple’s latest agreement accepted

Why. Apple updates the Apple Developer Program License Agreement from time to time, and only the Account Holder can accept it. While an update is waiting, App Store Connect can refuse the steps that send a build to testers.

Where in App Store Connect. Business, signed in as the Account Holder.

In VibeView. Distribution stops with Accept Apple’s latest agreement on the build’s card. When the callout says VibeView checks again every 30 minutes, it continues on its own once the agreement is accepted.

Otherwise, choose Check again after the Account Holder accepts it.

3. A build number Apple hasn’t seen

Why. Apple refuses a build number (CFBundleVersion) it already has. A build Apple rejects in Beta App Review is also replaced by a new build with a higher number, not resent.

Where in App Store Connect. TestFlight → Builds, under the platform, lists the build numbers Apple already has.

In VibeView. The Submit dialog’s Ready to send list says whether the build number is newer than the latest TestFlight build, and vibeview submit --check prints the latest TestFlight build number (CLI 0.56.0 or later). With automatic build numbers, every production build gets the next number from a counter per app and platform. Set the counter under Builds → Stores → your app → Edit → Build number, or with vibeview versions set.

4. Export compliance answered

Why. Apple asks, for every build, whether the app uses encryption beyond the exempt cases (HTTPS and the operating system’s standard cryptography). A build without an answer shows as Missing Compliance, and testers don’t get it. Apple may also need your export compliance documents.

Where in App Store Connect. TestFlight → the build → Manage, next to Missing Compliance. Or set ITSAppUsesNonExemptEncryption in the app’s Info.plist, and the question is answered by the build itself.

In VibeView. VibeView answers for you from the first of these that has an answer: your Info.plist, then the answer saved for the app. The Submit dialog asks once per app, and the answer is saved for every later build.

You can also pass --uses-encryption or --no-uses-encryption to vibeview submit (CLI 0.55.0 or later), or run vibeview testflight encryption (CLI 0.56.0 or later). With Yes, the build waits until you upload your documents in App Store Connect; VibeView doesn’t upload them for you. Fix TestFlight “Missing Compliance” walks through the answer and the Info.plist key, including for Expo apps.

5. Beta test information in every language

Why. Before Beta App Review, Apple needs test information for the app: a beta app description in each language the app has, and a feedback email, which is where testers send feedback and the reply-to address of their invitation emails.

Where in App Store Connect. TestFlight → Test Information, under Additional, one language at a time.

In the dashboard. Open TestFlight details from Builds → Stores → your iPhone, iPad or Apple TV app (or from the Submit dialog) and fill in Test information: the description (up to 4,000 characters), feedback email, marketing URL and privacy policy URL (for Apple TV apps, the tvOS privacy policy). The Language list marks a language that still needs a description, and Add a language adds another of App Store Connect’s languages. Apple doesn’t let a field be emptied once it has text, so change it instead.

From the command line. vibeview testflight set-info --locale <code> sets one language (CLI 0.57.0 or later).

6. Beta App Review contact and sign-in account

Why. Apple’s reviewers need someone to contact: a first and last name, phone number and email. When reviewing the app needs a sign-in, they also need a user name and password, and Apple asks that the account stay valid for the whole review. Review notes are for anything else that helps the review, not the sign-in details.

Where in App Store Connect. TestFlight → Test Information → Beta App Review Information.

In the dashboard. TestFlight details → Beta App Review contact: the contact fields, notes, and Sign-in required with the user name and password. The password is sent to Apple and never kept by VibeView or shown again.

From the command line. vibeview testflight set-review-contact does the same (CLI 0.57.0 or later). It reads the password from a file, a pipe or an environment variable, never from the command line.

If a build already shows Add Beta App Review contact details, TestFlight Beta App Review contact and demo account covers the fix and what makes a demo account work for review.

7. What to Test notes

Why. What to Test is the note testers see with a build, telling them what to try. Apple asks for it when a build goes to an external group, and you can add it in more than one language.

Where in App Store Connect. TestFlight → the build → Test Details → What to Test.

In the dashboard. The Submit dialog’s What to Test field (up to 4,000 characters) is required while an external group is chosen, so the button stays off until you write a note. What to Test, by language adds other languages, and Reuse last notes copies in what you sent last time; the field never fills itself.

From the command line. Pass --what-to-test or --what-to-test-file (CLI 0.55.0 or later), and --notes-dir for other languages, one <code>.txt file per language (CLI 0.58.0 or later). When a group is external and there is no note, the command stops before uploading anything.

If Apple refuses one language, the others still go out and the submission’s card says which one wasn’t added.

8. An external group with testers

Why. External testers get builds through a group, and Apple allows up to 10,000 external testers per app. Apple requires an internal group before you create your first external one, so create an internal group first. Internal testing takes up to 100 App Store Connect users and skips Beta App Review.

Where in App Store Connect. TestFlight → + next to Internal Testing or External Testing creates a group. In an external group, + next to Testers invites people by email, and Create Public Link (under Testers) makes a public link.

In the dashboard. The Submit dialog’s Testers list shows the app’s groups, each marked Internal or External. A group marked Gets every build is shown checked.

When the app has no groups, Create a group opens TestFlight details → Groups, where New group creates an internal or external group.

Under an external group, type testers one per line (an email, or email, first name, last name) and choose Add testers, up to 100 at a time. Each person gets a result, such as added, invited (Apple emails them once a build is available to the group), already in the group, or refused with the reason.

From the command line. vibeview testflight groups lists the groups, create-group --internal or --external creates one, and add-testers adds people to an external group (CLI 0.57.0 or later).

Add TestFlight testers from the command line walks through a tester file and what each result means.

Adding internal testers, removing testers and creating a public link stay in App Store Connect.

9. One build of a version in Beta App Review at a time

Why. Apple reviews one build of each version at a time, and accepts up to six builds for TestFlight review in 24 hours. The first build you submit gets a full review; later builds of the same version might not.

Where in App Store Connect. TestFlight → that build → Remove from Review, if you want Apple to review the newer build instead.

In VibeView. Distribution stops with Another build is in Beta App Review on the new build’s card. Wait for the earlier build’s verdict, or remove it from review in App Store Connect. VibeView checks again on its own every 30 minutes and never removes a build from review for you.

10. Everything checked before you send

Why. A missing item doesn’t stop the upload. It stops distribution to testers afterward, so checking first means the build goes straight through.

In VibeView. Three places show what is still missing:

• vibeview testflight info (CLI 0.57.0 or later) shows the test information for each language, the Beta App Review contact, whether a sign-in password is set (never the password), the groups, and what is still missing before external testing, each with the command that fixes it.
• vibeview submit --check --platform ios --bundle-id <id> --group "<group>" needs no build. It says whether App Store Connect knows the app with your stored key. From CLI 0.56.0 it also lists the app’s groups and the latest TestFlight build number, says what external testers would wait for, and exits 1 for a group name the app doesn’t have.
• In the dashboard, the Submit dialog’s Ready to send list shows the build number check and, while an external group is chosen, whether test information and the Beta App Review contact are filled in, with Add it here. You can send without them; external testers wait until you add them.

Run the checklist on your next build

After you send

How long Beta App Review takes is up to Apple. VibeView checks on its own; if Apple hasn’t given a verdict after 7 days, the state turns to Waiting on Apple and VibeView keeps checking every 6 hours. When the build needs your action, its card names the fix and where to make it, and Check again looks at App Store Connect at once.

If Apple rejects the build, the card says Apple rejected this build in Beta App Review. Read Apple’s message in App Store Connect (TestFlight → App Review, under General), fix the issue, and send a new build with a higher build number. VibeView doesn’t resubmit a rejected build. Each build stays testable for 90 days after upload.

Apple’s rules on this page come from its TestFlight overview, Provide test information, Invite external testers, Provide export compliance information for beta builds and role permissions pages, and the App Store Connect API’s Beta App Review details reference (all checked 25 October 2026). VibeView doesn’t change them.

Frequently asked questions

Do internal testers need Beta App Review?

No. Internal groups get a build once Apple has processed it and export compliance is answered. Beta App Review is for external groups only.

Why is my build stuck before external testers get it?

Usually one of the items above is missing: test information, the Beta App Review contact, What to Test notes, the export compliance answer, or another build of the version is still in review. In VibeView, the build’s card names which one and where to fix it.

How long does Beta App Review take?

That is up to Apple, and VibeView doesn’t promise a time. It checks on its own, shows Waiting on Apple after 7 days without a verdict, and keeps checking every 6 hours.

Can I add external testers from the command line?

Yes. vibeview testflight add-testers --group "<group>" --email <email> adds people to an external group, up to 100 at a time, and --testers-file reads one tester per line. It needs a full-access API token. Internal testers are added in App Store Connect.

Does VibeView submit my app for App Store review?

No. VibeView gets the build to your TestFlight testers. Submitting a version for App Store review stays in App Store Connect.

Next: Upload to TestFlight without a Mac walks through the build, the upload and the submit command end to end.