Testers
Every build Ploa makes goes straight to TestFlight and Google Play internal testing. From there your agent manages who gets it; anything that emails people or opens a build to more testers waits for your OK.
Make an external TestFlight group called Beta with a public link for 200 people.
Write What to Test for the newest build from the changes since the last one, and give it to the Beta group.
Add the beta-testers@googlegroups.com group to the closed testing track.
Move every tester to the newest build and take the older ones away.
The tools behind these requests: Every MCP tool › Testers.
Who does what
| Who | What |
|---|---|
| Your agent | Reads TestFlight and Play's testing tracks (ploa_testflight_get, ploa_play_testers_get); makes and changes groups, writes What to Test and the beta information, picks which groups get a build, and answers a build's export compliance (ploa_testflight_save); adds and removes Play's tester Google Groups (ploa_play_testers_save). |
| Ploa | Puts every build on TestFlight and internal testing, so an internal group that gets every build has it at once; shows each build's beta review state; offers to move testers to the newest build. |
| You | Approve what reaches people: testers Apple emails, a build sent to beta review, a Google Group added to a track, and moving testers off old builds. Make Play's tester email lists in Play Console, since Play's API has none. |
An agent its owner made autonomous carries these out at once, recorded under its name; see Access and approvals.
TestFlight (iOS)
TestFlight has two kinds of groups:
| Group | Who | How builds reach it |
|---|---|---|
| Internal | Up to 100 people on your App Store Connect team | Right after Apple's processing. An internal group can be set to get every build on its own. |
| External | Up to 10,000 people, by email or through the group's public link | After Apple's beta review approves the build (the first build of a version; later ones usually go faster). |
Your agent, or you on the app's Testing page, can:
- Make, rename and delete groups; turn a public link on, with a limit on how many can join; turn tester feedback on or off.
- Add testers by email and see where each stands: invited, accepted, installed. Apple emails each one, so this asks for your approval. Remove testers.
- Write What to Test for a build, in each language.
- Choose which groups get a build. An external group gets it once beta review approved it.
- Answer a build's export compliance, when the app hasn't answered it for every build (see Export compliance).
- Fill in the beta information beta review needs: a description and feedback email per language, the marketing and privacy policy links, and a contact and demo account for the reviewer (the demo password is never shown back, only whether one is set). Ploa says what's still missing before a build can go.
- Send a build to beta review, so external testers can have it. This asks for your approval.
Google Play testing
| Track | Who |
|---|---|
| Internal testing | Up to 100 testers from email lists, available within minutes. Every Ploa build lands here. |
| Closed testing | Testers from email lists or Google Groups, on the closed track or tracks of your own naming. Google reviews its releases. |
| Open testing | Anyone can join from the store page; there's no list. |
Testers join through the track's opt-in link, which Ploa shows with each track's current release and its tester Google Groups. Your agent puts a build on closed or open testing by promoting it (you approve; see Google Play).
- Google Groups are the only testers Play's API takes. Your agent adds and removes them on an internal or closed track by the group's address, after your approval: everyone in a group can then join through the opt-in link.
- Email lists are made in Play Console only: the track's Testers tab › Create email list (a name and the testers' emails, or a CSV) › Save changes, then tick the list. Internal testing takes only email lists there.
- Play allows each app a limited number of changes a day, so your agent changes several groups in one go. When they're used up for the day, Ploa says that's why it couldn't read or change the groups.
New personal developer accounts on Google Play (made after November 13, 2023) must run a closed test with at least 12 testers opted in for 14 days in a row before the app can go to production; internal testing doesn't count. Then, in Play Console's dashboard, Apply for production; Google usually answers within 7 days. The setup guide walks you through it once the first build is on internal testing. See A new app's first production release.
Testers on the newest build
When a newer build is out, the app's Testing page offers, under the newest build's row, to move every tester to it and take the older builds away. A window lists each step so you can untick any, and it's one approval.
- TestFlight: the newest build goes first to the groups that don't have it. An internal group keeps seeing older builds, so the only way to take one away is to expire it, which can't be undone. Older builds are expired only once every group has the newest. An external group the newest hasn't reached yet keeps the builds it tests until the newest passes beta review, and a build that an App Store version still on its way uses (in review, waiting, rejected) is never offered for expiry.
- Google Play: a testing track serves only its current release, so moving testers means setting the track to the newest build. Play's API can't delete a bundle; a bundle on no track reaches no tester.
On the dashboard
The app's Versions tab › Testing shows both stores side by side: TestFlight's groups, testers and builds, and Play's tracks with their releases and Google Groups. Every change your agent makes shows there, and the approvals it asks for wait on the Approvals page and as a notification. The CLI has no tester commands: use your agent or the dashboard.