Mobile Beta Release — getting a build to testers
Two stores, two completely different shapes. The mistake that costs the most time is assuming
they behave alike and planning the release around the faster one.
|
iOS (TestFlight) |
Android (Play tracks) |
| Fast lane |
Internal testers — up to 100 team members holding Account Holder, Admin, App Manager, Developer or Marketing roles |
Internal testing track — up to 100 testers, fastest availability |
| Wide lane |
External testers — up to 10,000 |
Closed → Open testing |
| Review gate |
External requires Beta App Review: "have your first build already approved by App Review for TestFlight. Your builds are automatically sent for review once they're added to a group." |
No App Review for internal testing |
| Build lifetime |
90 days, then the build expires for testers |
No expiry |
| Distribution |
Apple hosts; testers use the TestFlight app |
Play hosts; testers opt in via a link |
The planning consequence: an external TestFlight build can sit in Beta App Review while the
Android build is already on testers' phones. If your QA cycle assumes both land together, it
doesn't. Use internal testers for the tight loop and reserve external for the wider round.
Which of these facts expire
The shapes above are stable; the numbers are store policy and they move. Apple has raised the
external-tester ceiling before (2,000 → 10,000) and the internal one (25 → 100). Nothing in this
skill records when it was last checked, because nothing here ever was — the Apple wording quoted in
references/testflight.md is verbatim, which makes it sourced but not dated, and a quote is
exactly as confident the day it goes stale as the day it was right.
| Stable — the reason to read this skill |
Expires — check before you rely on it |
| Internal is fast, external is reviewed |
The tester ceilings (100 / 10,000) |
| A TestFlight build has a finite life; a Play build does not |
The 90-day window |
| The first build of an external group goes to Beta App Review |
Review turnaround, and what triggers a re-review |
| Build numbers must increase, forever, per platform |
Track names and their availability |
Check the ceiling and the window in App Store Connect and the Play Console — the consoles
show your app's real limits, which beat any doc. Do not restate a number from memory if it is
not in the table above: asked about a platform or a tier not covered here, say so rather than
producing a plausible figure, because a recalled limit is indistinguishable from a checked one once
it is in a release plan.
The planning advice survives either way, which is the point of separating them: use internal
for the tight loop, reserve external for the wider round stays true whether the ceiling is 10,000
or 25,000.
Decision: which track does this build belong on?
| Who needs it |
iOS |
Android |
| The 5 people on the team, right now |
Internal testers |
Internal testing |
| QA / the wider company |
Internal (if ≤100 and they hold roles) |
Closed testing (email list or Google Group) |
| Real customers in a beta programme |
External group (Beta App Review) |
Closed or Open testing |
| Everyone, gradually |
— (use phased release on the App Store) |
Production + staged rollout |
Do not put non-employees in TestFlight internal. Internal testers must be App Store Connect
users on your team — which means giving them an account with real permissions on your app.
"Just add the client as an Admin" is how a customer ends up able to change your app's pricing.
Build numbers: the rule that prevents the most wasted uploads
Every upload needs a build number nobody has used before, for that version. Both stores
reject a duplicate — and on iOS you discover it after the archive, upload, and processing
wait.
- Never hand-increment in the repo. Two branches will collide, and the merge conflict is in
a file nobody reads.
- Derive it.
github.run_number is monotonic and free. app_store_build_number(live: false) + 1
asks Apple what it already has.
- Keep the version (marketing) in the repo and the build number from CI. They answer
different questions: version is what you tell users, build number is what distinguishes two
uploads of the same version.
Release notes are the point, not paperwork
A tester who does not know what changed reports nothing useful. "Bug fixes and improvements"
wastes the whole build.
- Say what to test, not what you did: "Checkout: try paying with a saved card — the crash
on Apply Promo should be gone."
- Both stores accept notes per build; automate them from the changelog or commits.
- Ship the same notes to both platforms, or your two tester groups test different things and
you cannot compare their reports.
What must never differ from production
A beta whose config differs from production tests the beta, not the app.
- Point betas at staging deliberately, and label it in-app (a visible build banner) — a
tester filing bugs against production data is worse than no tester.
- Same signing, same minification. A beta built without ProGuard/R8 or with a debug
entitlement is a different binary; the crash you are hunting may only exist in release.
- Ship source maps / dSYMs with the beta or the crash reports are unreadable stack noise.
Deep guides (read on demand, do not preload)
- TestFlight end to end — internal vs external groups, Beta App Review, the 90-day expiry,
processing states,
upload_to_testflight options, and why builds sit in "Processing"
→ references/testflight.md
- Play testing tracks — internal/closed/open, opt-in links, promoting a build between tracks,
staged rollout and halting one,
.aab uploads with supply
→ references/play-tracks.md
- The fastlane lanes themselves — one beta lane per platform, build-number derivation, changelog
→ notes, dSYM/mapping upload, and the CI wiring
→
references/fastlane-lanes.md
Signing identities (certificates, profiles, keystores, API keys) are a separate concern — see
the mobile-signing skill. Do not debug a signing failure from here.
1---2name: mobile-beta-release3description: Build and ship React Native betas to testers — TestFlight (internal vs external groups, Beta App Review, 90-day build expiry) and Google Play testing tracks (internal, closed, open, staged rollout), with fastlane lanes, build-number strategy, and release notes. Use when shipping a build to testers or QA, setting up TestFlight or a Play internal/closed track, automating beta distribution in CI, deciding which track a build belongs on, or when someone asks "how do I get this to testers", "push to TestFlight", "Play internal testing", "staged rollout", or why a beta build is stuck in processing or review.4---56# Mobile Beta Release — getting a build to testers78Two stores, two completely different shapes. The mistake that costs the most time is assuming9they behave alike and planning the release around the faster one.1011| | iOS (TestFlight) | Android (Play tracks) |12|---|---|---|13| Fast lane | **Internal testers** — up to **100** team members holding Account Holder, Admin, App Manager, Developer or Marketing roles | **Internal testing** track — up to 100 testers, fastest availability |14| Wide lane | **External testers** — up to **10,000** | Closed → Open testing |15| Review gate | **External requires Beta App Review**: *"have your first build already approved by App Review for TestFlight. Your builds are automatically sent for review once they're added to a group."* | No App Review for internal testing |16| Build lifetime | **90 days**, then the build expires for testers | No expiry |17| Distribution | Apple hosts; testers use the TestFlight app | Play hosts; testers opt in via a link |1819**The planning consequence:** an external TestFlight build can sit in Beta App Review while the20Android build is already on testers' phones. If your QA cycle assumes both land together, it21doesn't. Use **internal** testers for the tight loop and reserve external for the wider round.2223### Which of these facts expire2425**The shapes above are stable; the numbers are store policy and they move.** Apple has raised the26external-tester ceiling before (2,000 → 10,000) and the internal one (25 → 100). Nothing in this27skill records when it was last checked, because nothing here ever was — the Apple wording quoted in28`references/testflight.md` is verbatim, which makes it *sourced* but not *dated*, and a quote is29exactly as confident the day it goes stale as the day it was right.3031| Stable — the reason to read this skill | Expires — check before you rely on it |32|---|---|33| Internal is fast, external is reviewed | The tester ceilings (**100** / **10,000**) |34| A TestFlight build has a finite life; a Play build does not | The **90-day** window |35| The first build of an external group goes to Beta App Review | Review turnaround, and what triggers a re-review |36| Build numbers must increase, forever, per platform | Track names and their availability |3738Check the ceiling and the window in **App Store Connect** and the **Play Console** — the consoles39show your app's real limits, which beat any doc. **Do not restate a number from memory** if it is40not in the table above: asked about a platform or a tier not covered here, say so rather than41producing a plausible figure, because a recalled limit is indistinguishable from a checked one once42it is in a release plan.4344**The planning advice survives either way**, which is the point of separating them: *use internal45for the tight loop, reserve external for the wider round* stays true whether the ceiling is 10,00046or 25,000.4748## Decision: which track does this build belong on?4950| Who needs it | iOS | Android |51|---|---|---|52| The 5 people on the team, right now | Internal testers | Internal testing |53| QA / the wider company | Internal (if ≤100 and they hold roles) | Closed testing (email list or Google Group) |54| Real customers in a beta programme | External group (Beta App Review) | Closed or Open testing |55| Everyone, gradually | — (use phased release on the App Store) | Production + **staged rollout** |5657**Do not put non-employees in TestFlight internal.** Internal testers must be App Store Connect58users on your team — which means giving them an account with real permissions on your app.59"Just add the client as an Admin" is how a customer ends up able to change your app's pricing.6061## Build numbers: the rule that prevents the most wasted uploads6263**Every upload needs a build number nobody has used before, for that version.** Both stores64reject a duplicate — and on iOS you discover it *after* the archive, upload, and processing65wait.6667- **Never** hand-increment in the repo. Two branches will collide, and the merge conflict is in68 a file nobody reads.69- Derive it. `github.run_number` is monotonic and free. `app_store_build_number(live: false) + 1`70 asks Apple what it already has.71- Keep the **version** (marketing) in the repo and the **build number** from CI. They answer72 different questions: version is what you tell users, build number is what distinguishes two73 uploads of the same version.7475## Release notes are the point, not paperwork7677A tester who does not know what changed reports nothing useful. "Bug fixes and improvements"78wastes the whole build.7980- Say **what to test**, not what you did: *"Checkout: try paying with a saved card — the crash81 on Apply Promo should be gone."*82- Both stores accept notes per build; automate them from the changelog or commits.83- Ship the same notes to both platforms, or your two tester groups test different things and84 you cannot compare their reports.8586## What must never differ from production8788A beta whose config differs from production tests the beta, not the app.8990- Point betas at **staging** deliberately, and label it in-app (a visible build banner) — a91 tester filing bugs against production data is worse than no tester.92- **Same signing, same minification.** A beta built without ProGuard/R8 or with a debug93 entitlement is a different binary; the crash you are hunting may only exist in release.94- Ship **source maps / dSYMs** with the beta or the crash reports are unreadable stack noise.9596## Deep guides (read on demand, do not preload)9798- TestFlight end to end — internal vs external groups, Beta App Review, the 90-day expiry,99 processing states, `upload_to_testflight` options, and why builds sit in "Processing"100 → `references/testflight.md`101- Play testing tracks — internal/closed/open, opt-in links, promoting a build between tracks,102 staged rollout and halting one, `.aab` uploads with `supply`103 → `references/play-tracks.md`104- The fastlane lanes themselves — one beta lane per platform, build-number derivation, changelog105 → notes, dSYM/mapping upload, and the CI wiring106 → `references/fastlane-lanes.md`107108Signing identities (certificates, profiles, keystores, API keys) are a separate concern — see109the `mobile-signing` skill. Do not debug a signing failure from here.
Kaakati