In this guide
These are conventions, not rules: teams use the words differently. The table gives a common reading. Store tracks (internal, closed, open) are a separate concept; see closed test vs staged rollout vs soft launch.
The stages
| Alpha | Beta | Release candidate | |
|---|---|---|---|
| Goal | Does the core work at all? | Does it work for people other than you? | Is this build ready to ship as is? |
| Completeness | Features may be missing or rough | Feature complete or nearly | Feature complete; only blocking fixes |
| Who tests | You, your team, a few trusted people | Outside testers who match your users | Same testers, plus a final check by you |
| Feedback you want | Crashes, broken flows | Usability, device issues, unclear parts | Only show-stoppers |
| Changes allowed | Anything | Fixes and polish; features rarely | Blocking fixes only |
| Exit condition | Core flows work | No major known issues | No blocking issues; you would publish it |
Practical use
- Do not skip the middle. Going from your own testing straight to launch means real users find the problems.
- Freeze scope at the RC. If you add features, it is a beta again.
- Write exit conditions down before each stage. Without them, stages never end.
- Match testers to the stage. Alpha: people who tolerate rough edges. Beta: people like your users. RC: whoever will notice a regression.
Where AppReviewX fits
Mostly the beta stage, for apps already published in a store: other developers give private, structured feedback (1 accepted feedback = 1 credit; new accounts at 0). Builds and installers are not distributed.
Related: all testing options, beta test vs soft launch, closed test vs staged rollout vs soft launch.