TestFlight Beta App Review contact and demo account

Before a build reaches external testers, Apple’s Beta App Review checks it. The reviewers need someone to contact and, if the app has a login, a way in. App Store Connect asks for this once per app, on the TestFlight test information page. Many first external builds stop there because nobody filled it in.

What Apple asks for

Apple’s App Store Connect API describes the Beta App Review details as contact information and demo credentials provided to reviewers. Its fields:

Field	Apple’s description
First name, last name, phone, email	The contact, in case Beta App Review needs to reach you
Sign-in required	Whether reviewers need to sign in to review all the app’s features
User name and password	The account reviewers sign in with. It must be valid and active for the whole review
Notes	Anything else that helps the review, up to 4,000 characters, without the demo account details

The App Review Guidelines (2.1, App Completeness) make the same point for any app with a login: include demo account information, and have your back-end service running. Apple also says that apps sent for TestFlight beta distribution should comply with the guidelines (2.2).

Where you see it

In VibeView’s Submit dialog, Ready to send says the contact details are missing while an external group is chosen. You can send anyway: internal groups get the build, and external testers wait until you add them.
On the build’s Store submissions card, it shows Needs your action with Add Beta App Review contact details. When Apple needs a sign-in account and none is set, the message names the sign-in account too. When you also chose internal groups, it adds “Your internal groups already have the build.”
From the command line, vibeview submit --wait-distribution exits 1 with the same message. vibeview testflight info lists what is missing before external testing, each with the command that fixes it.

Fix it in VibeView

Open Builds → Stores → your iOS or Apple TV app → TestFlight details. Or choose Add it here on the build’s Store submissions card or in the Submit dialog’s Ready to send list, which opens the right section. Under Beta App Review contact:

Fill in First name, Last name, Phone and Email.
If reviewers need to sign in, check Sign-in required, then enter the Sign-in user name and Sign-in password.
Add Notes if they help the review.
Choose Save.

What you save goes to App Store Connect at once; VibeView keeps no copy. The password is sent to Apple and never kept by VibeView or shown again. When Apple already has one, the field reads Set at Apple (type to replace): leave it empty to keep it, or type a new one to replace it. Unchecking Sign-in required removes the sign-in account from App Store Connect, and the dialog asks first (Turn off Sign-in required?).

When you save from a Store submissions card, VibeView checks with Apple at once, so a build waiting for these details moves on. Everyone in the organization can open TestFlight details; developers and admins can change it. A viewer’s card shows where to add the details in App Store Connect instead.

Fix it from the command line

vibeview testflight set-review-contact sets the same fields (CLI 0.57.0 or later, with a full-access token). Replace the names, phone, emails and file path with your own:

vibeview testflight set-review-contact \
  --first-name Ana --last-name Silva \
  --phone "+44 20 7946 0000" --email review@example.com \
  --sign-in-required --sign-in-user review-demo@example.com \
  --sign-in-password-file review-password.txt

There is no flag that takes the password itself, so it never shows up in your shell history or a process list. Give it one of these ways:

A file: --sign-in-password-file <path>. The password is used exactly as written, without one trailing line end.
A pipe: --sign-in-password-file - reads it from standard input, for example from your password manager’s command line tool. It refuses to read from a terminal, where the password would show on screen.
An environment variable: set VIBEVIEW_TESTFLIGHT_SIGN_IN_PASSWORD instead of the file (not both). It counts only when the command sets the sign-in account (--sign-in-required or --sign-in-user) or changes nothing else. So a pipeline can set it for every step.

Only the fields you pass change. --notes or --notes-file sets the notes. --no-sign-in-required removes the sign-in account from App Store Connect: it asks first, and without a terminal it needs --yes. --app and --asc-key choose the app and the stored App Store Connect key when vibeview.json doesn’t settle them.

Check the result with vibeview testflight info: it shows the contact and whether a sign-in password is set, never the password itself.

Fix it in App Store Connect

The details live on the app’s TestFlight test information page. Apple’s provide test information page shows the way there, and it needs the Account Holder, Admin or App Manager role:

In Apps, open the app and click the TestFlight tab.
In the sidebar, under Additional, click Test Information.
Fill in the Beta App Review Information: the contact’s name, phone number and email.
If reviewers must sign in, turn on the sign-in option and enter the user name and password.
Add notes if they help the review, then save.

A demo account that survives review

Use an account made for review, not a person’s own login, and keep it active for the whole review, as Apple asks.
Give it data. An empty account can make features look broken. Seed it with what reviewers need to see.
Cover every sign-in path. If users sign in with a social account, Apple asks for an account for that as well.
Put the how, not the password, in the notes. Use the notes for where a feature is, a test card or a setting reviewers need. Apple asks that the demo account details stay out of the notes.

After you fix it

A submission waiting for the contact details picks them up at its next check, within 30 minutes. To look now, choose Check again on the Store submissions card, or run vibeview submissions check <id>. VibeView then sends the build to Beta App Review and adds it to your external groups; Apple releases it to them after it approves the build.

In CI, a CI-only token can read these details with vibeview testflight info but can’t change them, so set them once from your own login or the dashboard. After that, every build of the app uses them.

If Apple rejects the 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.

The other things Apple needs before external testing, from export compliance to What to Test notes, are in the TestFlight external testing checklist.

Next: run vibeview testflight info for your app and fix what it lists, then add your external testers with Add TestFlight testers from the command line.

Frequently asked questions

Do internal testers need the Beta App Review contact?

No. Internal groups get the build once Apple has processed it and export compliance is answered. The contact details are for Beta App Review, which only external testing needs.

Does VibeView store the demo account password?

No. VibeView sends it to Apple and keeps no copy. It can’t show it again, and vibeview testflight info only says whether one is set.

Can I pass the password as a flag?

No. Read it from a file, a pipe or the VIBEVIEW_TESTFLIGHT_SIGN_IN_PASSWORD environment variable, so it never appears on a command line.

Do I enter these details for every build?

No. They belong to the app in App Store Connect, so set them once and every later build uses them. Change them when the contact or the demo account changes.

My app has no login. Do I still need a contact?

Yes. The name, phone number and email are needed either way. Leave Sign-in required unchecked.

Apple’s pages referenced here were checked on 25 October 2026.