App guide · 10 Nov 2026 · 4 min read
App beta testing: how TestFlight and Google Play testing work
Before an app reaches the public, it should be in the hands of real people on real phones. Apple and Google each provide a way to do this. Here is how they work and how to run a useful test.
The short answer
On iPhone, TestFlight lets you send pre-release builds to internal and external testers. On Android, Google Play Console offers internal, closed and open testing tracks before production. Decide who tests, give them tasks, collect feedback in one place and fix what blocks launch. Check each store's current rules for limits and requirements.
Why test outside your own team
Developers test on a few devices, with good connections and full knowledge of how the app should be used. Real users arrive with older phones, patchy mobile data, different languages and no idea what you intended. A beta test lets you meet those conditions before launch, when a fix costs a day, not a bad review.
A beta is not a substitute for earlier steps. Prototype testing, covered in wireframes and prototypes, checks whether people understand the idea. Beta testing checks whether the finished build works.
TestFlight for iPhone and iPad
TestFlight is Apple's tool for distributing pre-release builds. Your developer uploads a build to App Store Connect and chooses who receives it. Testers install the TestFlight app from the App Store and then the beta from within it.
- Internal testers are members of your App Store Connect team. They can get builds quickly and are suited to the team and trusted colleagues.
- External testers are outside people invited by email or by a public link. A build sent to them may need a short review by Apple first.
Builds in TestFlight do not last forever; they expire after a set period, so keep fresh builds available. The numbers of testers and the length of that period are set by Apple, so check the current documentation before planning. Testers can send feedback and screenshots through TestFlight, and your developer can see crashes and usage reports for the beta.
Testing tracks on Google Play
Google Play Console uses tracks, which are channels that deliver a build to a chosen group.
| Track | Who gets it | Typical use |
|---|---|---|
| Internal testing | A small list of testers you name | Quick checks by the team |
| Closed testing | Invited testers, by email list or group | A planned beta with known participants |
| Open testing | Anyone who finds and joins the test on the store | A wider public beta |
| Production | Everyone | The real release |
You can run several closed tests, and one open test, at the same time. Google has also set extra testing requirements for some newly created developer accounts before they can publish; the rules and numbers have changed in the past, so read the current Play Console help before you plan dates. A developer account takes time to set up, so start it early.
Privacy, accounts and store forms
Testing does not make you exempt from rules. Google's help states that apps active only on internal testing tracks do not need the Data safety section, but closed and open tests do. Apple asks for privacy information when you prepare a release. Read privacy labels and data safety forms before inviting outside testers.
Tell testers what data the beta collects and how to give feedback. Do not give them real customer data, and never put production secrets in a beta build. For wider safety points, see mobile app security basics.
Running a useful beta
- Set the goal. Are you hunting crashes, checking the sign-up flow, or testing a new feature on many devices?
- Pick the people. Include people who match your real audience, on a spread of phones and operating system versions, and in the countries you plan to serve.
- Give tasks. A short list such as "create an account, add an item, restart the app and check it is still there" gets better feedback than "tell us what you think".
- Make feedback easy. One form or one email address, with space for the phone model and screenshots.
- Set a time frame. A week or two with a clear end date keeps testers engaged.
- Close the loop. Tell testers what you fixed.
Install a crash reporter in the beta build so faults show up even when testers do not report them; see crash reporting and monitoring basics.
A short test script to give your testers
Testers do better with a short list of tasks than with an open invitation. Here is an example for an imaginary booking app; replace the steps with the main journeys in your own.
- Install the beta and open it for the first time. Note anything confusing.
- Create an account and sign in again after closing the app.
- Make a booking, then change it, then cancel it.
- Turn on flight mode and see what the app does.
- Change the phone language or text size and look for text that is cut off.
- Send us a screenshot of anything that looked wrong, with your phone model.
Ask a few testers to repeat the tasks on a slow connection, and at least one to use a larger text size. Thank everyone for their time. Testers who see their feedback lead to a fix are more likely to help again.
Turning feedback into decisions
Sort what you receive into three piles: faults that block launch, problems worth fixing soon, and ideas for later. Resist the urge to add features in the middle of a beta, because each change needs testing again. Keep a record of which build each tester used so you can tell whether an issue still exists in the latest one.
Beta feedback often shows that people do not understand the first screens, so revisit the design of the first screens if testers stall early. Decide a clear exit rule in advance, such as no known crashes in the main flows. When you reach it, move on to preparing the store listing, as in app store screenshots and previews, and then to review. Reasons for failing that review are listed in why apps get rejected.
If you need help planning or running a test, see our mobile app development service.
Related guides
- Mobile app development
- App Store Screenshots and Previews: How to Make Them
- App Maintenance After Launch: What to Plan For
- App store optimisation basics
- What to build in the first version of your app
- Google search console for beginners
Questions and answers
What is TestFlight?
It is Apple's tool for sending pre-release iPhone and iPad builds to testers. Testers install the TestFlight app, accept an invitation and try the beta. It supports internal team members and external invitees.
Does an external TestFlight build need Apple's review?
Builds for external testers may need a short review by Apple before they can be distributed. Check the current App Store Connect documentation for when this applies.
What are the Google Play testing tracks?
Internal, closed and open testing, followed by production. Internal is for a small named group, closed is for invited testers and open is available to anyone who joins from the store.
How many testers do I need?
Enough to cover your main devices, operating system versions and user types. There are also store limits and, for some new Google developer accounts, testing requirements. Check the current documentation for both.
Do beta builds need privacy declarations?
Often yes. Google states that only internal-track apps are exempt from the Data safety section, and Apple asks for privacy information when you prepare a release. Check each store's current help pages.
How long should a beta last?
Long enough for testers to complete the planned tasks and for you to fix and retest blockers, commonly a week or two. Set the end date and exit rule in advance.
Tell us what you are building.
A short call, a written plan and a fixed quote. No obligation.