Release track
The store lane that decides whether a build goes to your team, beta testers, or the public.
See it
What it is
A release track is a store lane that decides who can install a build. Google Play names the lanes internal testing, closed testing, open testing, and production. Apple divides the same journey between TestFlight internal and external groups, then the public App Store, even though App Store Connect does not call all of them tracks.
Use the lanes as gates. Put every build through the internal audience, promote a candidate to a closed beta, and send only a known-good version to production. Keeping the package name, signing identity, and product configuration constant makes the tested artifact much closer to the one customers receive.
Gotcha: changing the audience leaves the normal store rules in place. External TestFlight builds can need beta review, testers must join with the right store account, and Android version codes must keep increasing across tracks. A production track is also separate from a percentage rollout: one chooses the audience, the other meters delivery within it.
Ask AI for it
Create a release-track pipeline for this app using the Google Play Developer Publishing API edits.tracks.update method and App Store Connect API TestFlight groups. On every signed tag, upload one immutable signed artifact per platform, assign each to internal testing, run these smoke tests [paste], then require explicit approvals before closed beta and production. Return the CI configuration, required secret names without secret values, version-code and build-number checks, promotion commands, and rollback procedure. Keep percentage rollout as a separate production step, and fail the pipeline if it tries to reuse an Android versionCode or promote a different binary than the one tested.