The Complete App Beta-Testing Workflow: iOS, Overseas Android, and Domestic Channels

Between developing an App and putting it in front of real users sits a layer of work that's easy to underestimate: closed and open beta testing. iOS and Android each have their own vocabulary and rules, and those rules keep changing — for example, since late 2023, Google Play has added a mandatory gate for newly registered individual developer accounts that many people only run into once they've started. This article distills the full workflow, timing, and common pitfalls of all three lanes — iOS (TestFlight), overseas Android (Google Play), and Chinese Android channels — into a checklist you can follow directly, aimed at indie developers and small teams.

First, align on the concepts

In Chinese, the terms for "closed beta" (内测) and "open beta" (公测) don't map one-to-one onto each platform's official terminology, so let's settle on a shared vocabulary first — that keeps things from getting muddled later.

iOS / TestFlight

Two kinds of testing groups

The lifecycle of a build

• Every build is valid for 90 days after upload; once it expires it's automatically disabled, and testers can no longer download it or launch the test entry point.
• You can submit at most 6 builds to Beta Review in a single day.
• The build number must strictly increase; any change to the marketing version (CFBundleShortVersionString) triggers a fresh round of review for the first build.

Public link vs. email invite

A safe cadence

Day 0    Upload the first build
         → Add it to the Internal Group → core members run it first
         → Fix the obvious bugs that night or the next day

Day 1-3  Push several fixed builds, still Internal-only
         → Get 1–2 core scenarios to a no-major-issues state

Day 3-5  Add the passing build to the External Group → submit for Beta Review
         → Wait for approval within 24 hours

Day 5+   Once Beta Review passes, open the public link and start recruiting for open beta
         → The What to Test text can be edited later; no need to re-upload the binary

Common Beta Review rejection reasons

• Missing test account: if there's a login feature, you must provide a working demo account.
• Certain emoji in What to Test: some symbols (like the globe or the memo/notepad) trigger a review rejection, so it's best to draft with plain text first.
• Third-party login is involved but not explained, or the login callback doesn't work in the test environment.
• The description badly mismatches the App's actual features.
• In-app purchases/subscriptions haven't been successfully run through the Sandbox flow.

Android / Google Play (overseas)

Three testing tracks

Google Play Console offers three parallel testing tracks that can coexist, but a single device can only join one of them at a time.

Closed Testing: the gate new accounts can't dodge

This is a rule that's easy to trip over, and the single thing this article most wants to flag: for individual developer accounts registered after 2023-11-13, the path to publishing a production release has been forcibly lengthened.

• You must run Closed Testing first.
• You need at least 12 testers who stay opted in continuously for 14 days.
• Only after passing can you apply for Production access (publishing the production release).
• Those 12 testers must be real Google accounts, and they must explicitly opt in (click the link, accept).
• The 14-day countdown is continuous: if someone drops out midway, the count resets.
• Organization accounts aren't subject to this, but it's worth doing anyway to build up some early word-of-mouth.

In practice, indie developers usually have to scrape together five or six real accounts of their own, then reach the full 12 through tester-swap communities (like Reddit's r/AndroidBetaTesting or related Discord mutual-testing groups).

Upload format

• You must use AAB (Android App Bundle); Production no longer accepts a bare APK.
• You can validate locally on the command line with bundletool; CI commonly uses Gradle Play Publisher or Fastlane supply.
• The same versionCode can't be uploaded twice to any track.

Recommended cadence

New account:
  Internal (run 1-2 weeks of self-testing)
  → Closed Testing with 12 opted-in testers (hard policy gate)
  → After the full 14 days, apply for Production access
  → Only after approval can you use Open Testing for open beta / go straight to Production

Old account / Organization account:
  Internal → Open Testing (open beta) → Production
  (Closed can be skipped, but a small round of Closed to gather feedback is recommended)

Chinese Android channels (when Google Play isn't available)

Third-party distribution platforms

When Google Play isn't in the picture, the easiest option for the closed-beta stage is a general-purpose distribution platform: a single link plus a QR code gets the package into testers' hands.

A typical flow on these general-purpose platforms: after you upload the APK/IPA, it auto-generates a download page, a QR code, and a short link; then you set whether a password is required, whether to limit the device count, an expiry date, and whether login is required; once you send the link to testers, the platform can also track install counts and the distribution of device models and versions.

The major app stores' own Beta channels

Most of the major domestic stores have their own closed-beta / staged-rollout entry points, so you can run a round before the official launch.

A few practical lessons for the domestic side

• Early closed beta: a single general-purpose distribution link handles it — the least hassle.
• Open beta / launch: use "multi-channel distribution" to submit to the mainstream markets in one pass.
• If you want something close to the "App Store 90-day Beta experience": go with Huawei AGC's open-beta version, which is the closest to a standardized process.
• A special case for iOS in mainland China: TestFlight's distribution domain is sometimes unstable at the network layer (intermittently unreachable), but the App itself works fine once installed; having testers switch networks and retry usually fixes an install/update entry point that won't open.

Cross-platform cadence: shipping the same App on iOS + Android at once

Week 0    Freeze the main feature set
          iOS: push to TestFlight Internal
          Android: push to Play Internal Testing + domestic general-purpose distribution

Week 1    Core bugs fixed
          iOS: submit for External Beta Review
          Android (international): open Closed Testing, recruit 12 opted-in testers

Week 2-3  iOS: External passes → open beta via public link
          Android (international): Closed hits 14 days → apply for Production access
          Domestic Android: widen the open-beta reach

Week 4+   iOS: submit the production release for App Store review
          Android: Production launch + keep Open Testing as an ongoing Beta
          Domestic: publish on the major stores

Common pitfalls

iOS

• Assuming Internal also needs review → waiting for nothing. Internal doesn't need Beta Review.
• Bumping the marketing version too often → each time you have to re-pass the review for the first build.
• Stuffing special-character emoji into What to Test → rejected.
• Forgetting to ship a new build as the 90 days approach → testers suddenly drop off en masse.
• Not communicating/confirming before pushing a new build → for teams collaborating on a rhythm, it's worth baking "confirm before pushing" into the process.

Android (overseas)

• A new account applying for Production directly → blocked; you must first complete the full 14 days of Closed.
• Rounding up acquaintances for Closed Testing but not having them click the opt-in link → they don't count.
• A tester drops out midway → the 14 days restart.
• One device joining multiple tracks at once → only one takes effect, which often leads to misdiagnosed bugs.

Domestic Android

• Each store's "qualification review" standards differ; business licenses / software copyright registrations often get held up.
• Some stores require that the privacy-policy URL not be a third-party online document (like certain cloud-document platforms) — it must be a page on a standalone domain.
• Free-tier distribution platforms limit single-file size and download counts, so check your quota before load-testing a large release.

A checklist you can follow directly

• Before pushing a new iOS build, make "confirm within the team" a fixed step.
• Draft What to Test in plain text first; use only emoji you've confirmed are safe.
• Keep an eye on the 90-day validity: upload a new build every 2–3 weeks so testers don't drop off.
• Before building the Android version, decide: do you need Google Play overseas? Pick which track you'll take before you start, and new accounts especially should budget Closed Testing's 14 days into the schedule.
• For domestic Android, prefer a general-purpose distribution platform for the closed beta, then use multi-channel distribution for the official launch.

References

iOS

• TestFlight overview (official): developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/
• Invite external testers (official): developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers/
• TestFlight product page: developer.apple.com/testflight/

Android (overseas)

• Set up an open, closed, or internal test (official): support.google.com/googleplay/android-developer/answer/9845334
• The new-account 12 testers / 14 days policy (official): support.google.com/googleplay/android-developer/answer/14151465

Chinese Android

• Pgyer (蒲公英) official site: www.pgyer.com
• fir.im domestic site: www.betaqr.com.cn