Setting Up TestFlight and Google Play Testing Tracks for a Beta

The two-store testing landscape at a glance

Setting up TestFlight step by step

1. Upload a build from Xcode, Xcode Cloud or your CI (for example with Fastlane). Increase the build number for every upload.
2. Answer export compliance. Add the ITSAppUsesNonExemptEncryption key to Info.plist so you do not have to answer the encryption question for each build.
3. Fill in test information: what to test, a beta app description, a feedback email and – if the app needs a login – working demo credentials for Beta App Review.
4. Create an internal group for your team and enable automatic distribution, so every processed build reaches developers and QA immediately.
5. Create external groups per audience – pilot customers, friendly users, a partner company. Add the build; the first build of each version goes to Beta App Review, which is usually faster than a full App Store review.
6. Invite testers by email or a public link. Public links can be capped at a maximum number of testers, which keeps a pilot under control.

Testers install the TestFlight app, accept the invitation and can send screenshots and crash feedback directly. Remember that TestFlight builds expire after 90 days, so long-running pilots need regular uploads.

Setting up Google Play testing tracks

Google Play organizes testing in tracks. Upload an Android App Bundle and create a release on the track you need:

• Internal testing is for your team. Add testers by email list; they join through an opt-in link.
• Closed testing suits external pilots. Use Google Groups for larger audiences, because adding a group member is easier than editing lists in the Play Console. You can run several closed tracks in parallel, for example per customer.
• Open testing makes the beta joinable from your store listing, with an optional cap on testers.

Newer personal developer accounts must run a closed test with at least 12 opted-in testers for 14 consecutive days before they can apply for production access. Organization accounts are not subject to this rule. Closed and open tracks also produce a pre-launch report, in which Google installs the app on test devices and flags crashes, accessibility issues and security warnings – read it before you promote a release.

Managing testers and feedback

• Write short release notes for testers with every build: what changed, what to focus on.
• Give one feedback channel. TestFlight feedback and Play's private tester feedback are useful, but pilot customers often prefer email or a form; route everything to one issue tracker.
• Keep tester data minimal. Tester email addresses are personal data; tell testers what is collected and remove them when the pilot ends.
• Do not confuse a beta with a launch. Store metadata, screenshots and privacy declarations are still needed for production review.

How jocapps can help

appsubmitter.io sets up TestFlight groups, Google Play tracks and the CI/CD pipeline that feeds them, in your own developer accounts, and helps when a beta or production review stalls. If your new personal Play account faces the 12-tester rule, read our guide to the Google Play closed testing requirement. For a broader release plan, see our App Store launch service or book a free 30-minute call via the meeting planner.