TestFlight beta testing checklist

This checklist is about operating a useful beta: who to invite, what to ask, what Apple will review, and what usually delays an external group. The wider submission timeline lives in the launch process. Tester limits and the lifetime of a build can change; confirm the current figures in App Store Connect’s TestFlight documentation rather than treating a number as permanent. As of Apple’s current documentation, a build can be tested for up to 90 days from upload, internal testers are drawn from App Store Connect users on the account, and you can invite a large external group per app — but you should re-read those limits when you set the group up.

What you want the beta to teach you

Start with a written question, not with a list of email addresses. “Does the sign-in and the first useful task work on a phone that is not mine?” is a good question. “Please try the app” is not.

A useful beta for a small app usually has one of these jobs:

• A crash and regression pass, close to a release, on a handful of devices you do not use daily.
• A first-run pass, with people who have never seen the app, to find the moments where the UI goes quiet.
• A feature pass, with a short list of tasks, when you have changed something that is hard to test alone.

Write the question at the top of the “What to Test” notes in App Store Connect, and in the message you send to testers. If you cannot say what a good report looks like, you are not ready to invite anyone. That is the same scoping habit I want in an MVP checklist: a small, named outcome, not a vague hope that someone will “look around.”

Automated tests still come first. A beta is expensive compared with a unit test that you already know how to run. The guide to testing iOS apps with Swift Testing is the foundation; TestFlight is for the things those tests cannot see.

Internal testers first

Internal testers are people who already have an App Store Connect role on your team. They can usually install a build as soon as it has been processed, without waiting for Beta App Review. That is why they should go first. Apple currently documents a modest cap on internal testers (on the order of a hundred accounts with access); confirm the live number when you add people.

A practical internal group for a solo developer might be: you, one person on a different phone size, and one person on a slightly older iOS version. If you have a collaborator or a client, they belong here once they have an App Store Connect seat, not in a public link.

What you want from this group is fast and unsentimental:

• the app installs
• it launches on a clean account and on an existing account
• the main task can be completed
• crashes, obvious layout breaks and missing permission strings are reported before a stranger sees them

Don’t wait a week for internal testers if they are silent. A build that only you have opened is not an internal beta; it is a personal install. Nudge once, with the same short task list you will later give to external testers.

External testers and Beta App Review

External testers are people who are not on your App Store Connect team. You invite them by email, or with a public link, into a group that has a build assigned to it. Apple currently documents a large cap on external testers per app (in the thousands); again, confirm the live limit rather than designing around a remembered figure.

The first build of a version that you add to an external group is typically sent to TestFlight App Review. Later builds of the same version may not need a full review, but they might. Review is against the App Review Guidelines; a beta is not a free pass for a broken login, a hidden feature, or placeholder content you would not ship.

Things that commonly delay or fail that review:

• a missing or vague privacy policy URL, if the app collects data
• incomplete export compliance answers
• sign-in that the reviewer cannot use, with no demo account in the Test Information
• a crash on launch
• content or services that are not yet finished, presented as if they were

You can only have a limited number of builds in that review state at once (Apple currently documents a small daily cap on submissions). Don’t burn the queue on a build you have not even run yourself.

Public links are convenient and easy to lose control of. If you use one, consider the criteria App Store Connect now lets you set (device or OS), and be ready to expire the link. A public link is not a substitute for a brief, and it will attract people who never report back.

Information, required notices and export compliance

Before anyone outside the team can test, App Store Connect wants Test Information: a feedback email, contact details, notes, and, where relevant, a demo account and a privacy policy URL. Fill these in as if a reviewer who has never met you will use them, because that is the case.

Export compliance is the usual trap. If the build uses encryption — and almost every app that talks to the internet does, at least through HTTPS — you will be asked to answer questions, and sometimes to provide documentation. A build can sit in “Missing Compliance” until you do. Answer the questionnaire carefully, keep a copy of the answers you gave, and don’t tick the first box that seems to make the yellow banner go away. Apple’s current Help pages on cryptography and export compliance are the source, not a forum thread from 2018.

Other notices that testers will see, and that you should not leave as leftovers:

• the beta disclaimer TestFlight already shows; you don’t need to repeat it as legal theatre, but you should not contradict it
• any in-app purchases: Apple currently documents that in-app purchases can be made without charge during a beta, and that they do not carry over to the App Store version. Tell testers that clearly, especially if your app is paid or subscribed.
• sign-in with a real account: if testers will use their own data, say what you will do with it, and give them a way to have it deleted.

The Website Brief & Quote Builder is an odd tool to mention here, but it is a useful place to draft the short “what this is, who it is for, what I need from you” paragraph before you paste it into What to Test. The brief should be shorter than you think.

What to ask testers, and how they reply

Testers are not a substitute for a script. Give them:

1. The question you are trying to answer.
2. A short task list, in order, that a new user can finish in one sitting. “Create an account, add one item, export it” is a list. “Explore the new design” is not.
3. The setup, if any: demo account, required OS version, whether they need a Watch or a second device.
4. How to report, and what to include: the steps, what they expected, what they saw, a screenshot, and whether they will let you follow up.

TestFlight itself collects crashes and lets testers send screenshots with comments from the TestFlight app or from the screenshot flow. Ask them to use that for anything that is visual or crash-related, so the build number travels with the report. For a longer opinion, a short email is fine, if you have told them the address.

Don’t ask ten people the same vague question and then try to average the answers. If you want a first-run opinion, watch one or two people (even on a call) go through the task list, and use the rest of the group for coverage on devices you don’t own.

Reply. A tester who sent a careful note and heard nothing will not send a second one. You don’t need a product-management platform; a short thank-you and a sentence about what you will change is enough.

Expiry, replacements and groups

A TestFlight build does not last for ever. Apple’s current documentation says a build is available for up to 90 days from upload, after which testers can no longer open it. App Store Connect will show you when a build is close to expiring. Don’t discover it because a tester emailed you on the 91st day.

A workable rhythm:

• Upload a new build before the old one expires, even if the only change is “still testing the same feature,” if people are still in the programme.
• Expire a build yourself when you do not want it used (a bad regression, a leaked link, a backend you have switched off). Expiring is a deliberate act in App Store Connect.
• Use groups for different jobs: a small internal group, a trusted external group, and, if you must, a public-link group with a narrower brief. Assign builds to groups on purpose; don’t dump every build into every group.
• Name versions clearly. The marketing version and the build number should mean something to you when a tester says “I’m on 1.2 (44).” A conventional commit history and a changelog generated from those commits make the What to Test notes easier to write, because you can see what actually landed.

If you submit the same build to the App Store, testers who already have it can often keep testing until the 90-day window ends. Don’t rely on that as your only distribution; the beta and the store are different products with different expectations.

Crashes, signing and the usual delays

Most “TestFlight is broken” delays are not TestFlight. They are, in roughly this order:

• The build is still processing, or was rejected as an invalid binary. Read the email, fix the issue, upload again.
• Missing export compliance, which looks like the build is ready when it is not.
• A missing application identifier in the provisioning profile, which can make a build unavailable for testing at all.
• Signing or capability mismatches: a Push, associated domain, or App Group entitlement that the profile doesn’t have, or a debug-only configuration you accidentally shipped.
• The tester is on an OS or device you excluded, or they opened an expired build, or they used a managed Apple Account that cannot install TestFlight builds (Apple documents restrictions for some managed accounts).
• A crash on launch that you didn’t see because you always start from a warm, signed-in state. Install the build on a clean simulator or a reset test device before you invite anyone.

When a tester reports a crash, look it up in the TestFlight or Xcode Organizer crash reports for that build before you ask them to “try again.” If you cannot reproduce it, ask for the OS version, the device, and whether they were signed in. Then file it, don’t argue with it.

A checklist from first build to sign-off

• You have written the question the beta should answer, and a short task list that matches it.
• Automated tests for the same area have been run; the beta is not your first check.
• Test Information is complete: contact email, notes, demo account if needed, privacy policy URL if needed.
• Export compliance questions have been answered for this build, not copied blindly from memory.
• You have installed the build from TestFlight on a device that is not your everyday phone, including a cold first launch.
• Internal testers have had a chance to fail the task list, and any crash-on-launch is fixed.
• External testers (if any) are in the right group, with a What to Test note and a way to reply; a public link is intentional.
• Beta App Review, if required, has been submitted with information a stranger can use.
• In-app purchases and data use during the beta have been explained to testers.
• You know when the build expires, and you have a plan to replace or expire it.
• Feedback and crashes have been triaged, and testers have been thanked.

When the question you wrote at the top has been answered — yes, it works; no, the first run still fails at step three — the beta has done its job. You can then decide whether to ship, in the ordinary launch sense, or to cut another build.

Key takeaways

• Start a TestFlight programme with a question and a short task list, not with a blank invitation.
• Use internal testers first; they can usually install without Beta App Review and will catch the obvious breaks.
• External groups often need TestFlight App Review, complete Test Information, and honest export-compliance answers.
• Builds expire; Apple currently documents a 90-day window, which you should confirm and plan around.
• Close the loop: triage crashes, thank testers, and replace or expire builds on purpose.

If you want a second pair of eyes on a beta plan, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.