TestFlight and Firebase App Distribution

Friday afternoon, a banking app team. The developer says “the transfer bug is fixed, can you check?” The tester opens the app, tries a transfer, and it fails again. Bug reopened. Developer: “Works for me.” Twenty minutes of back-and-forth later they find the problem: the tester was still on yesterday’s build. The fix was in a build that had arrived in TestFlight an hour earlier, which nobody had installed.

That’s the whole topic in one story. On mobile you can’t just refresh a page to get the latest code. Every change has to become a new buildBuildA specific compiled version of the app or website that is ready to be installed or tested.Open in glossary →, get delivered to your phone, and be installed. Knowing how that delivery works, and always knowing which build you’re holding, is a basic tester skill.

Why beta distribution exists

Developers can install an app straight from Xcode or Android Studio onto a phone plugged into their computer. That’s fine for one person, but a team needs something better:

• Real builds on real phones. Testers need the same kind of build users will get (signed, optimized, with push notifications and payments working), installed on real devicesReal deviceA physical phone or tablet used for testing, as opposed to an emulator or simulator.Open in glossary →.
• Many testers, no cables. QA, product managers, designers and sometimes thousands of customers need to install new builds with one tap.
• Before the store. Once something is in the App Store or Google Play, every user gets it. Beta distribution is the last safety net before a releaseReleaseMaking a version of the software available to users.Open in glossary →.
• Feedback and crash reports from testers flow back to the developers, tied to the exact build.

There are three main channels you’ll meet: TestFlight (iOS), Google Play testing tracks (Android) and Firebase App Distribution (mostly Android, also iOS).

TestFlight (iOS)

TestFlightTestFlightApple's service for distributing beta builds of iOS apps to testers before App Store release.Open in glossary → is Apple’s beta service, part of App Store Connect. Testers install Apple’s free TestFlight app from the App Store, and beta apps are installed through it.

	Internal testers	External testers
Who	Members of your App Store Connect team (with a role like Developer or Marketing)	Anyone with an email address
How many	Up to 100	Up to 10,000
How they join	Added in App Store Connect, invited by email	Email invitation or a public link
Review	None: builds are available as soon as they’re processed	The first build of a version needs Beta App Review (usually quick)
Typical use	Daily QA builds	Wider beta with customers or other departments

Things every TestFlight tester should know:

• Builds expire after 90 days. An expired build can’t be opened anymore. If someone reports a bug on an expired build, it needs to be checked on a current one.
• “What to Test” notes come with every build. Read them first: they tell you what changed and what the team wants checked.
• Version and build are shown on every build, for example Version 2.4.0 (318). Many builds can share one version; the number in brackets is the one that matters.
• Previous builds. In the TestFlight app you can install an older build of the same app (as long as it hasn’t expired). Useful for checking “did this work before?” and for upgrade testsUpgrade testingChecking that updating from an older app version keeps the user's data and settings working.Open in glossary →.
• Feedback with screenshots. Take a screenshot while using a beta app, tap Share Beta Feedback, add a comment and send it. After a crash, TestFlight can ask you to share details. Both arrive in App Store Connect together with the device, OS and build number.
• Installing over the store app. A TestFlight build replaces the App Store version of the same app (and keeps its data). To go back, reinstall from the App Store.

Google Play testing tracks (Android)

Google Play has its own beta system built into the Play Console. The team uploads a build to a track, and testers who joined that track get it through the normal Play Store app, like a regular update.

Track	Who can join	Notes
Internal testing	Up to 100 testers chosen by email	Fastest: available within minutes. Great for daily QA builds.
Closed testing	Invited testers (email lists or Google Groups)	For a bigger, controlled group. At the time of writing, new personal developer accounts must run a closed test with at least 12 testers for 14 days before they can publish to production.
Open testing	Anyone, from the app’s Play Store listing	A public beta. Your app’s store page shows a “Join the beta” option.

Testers first opt in with a link from the team, then install or update the app from Google Play. To go back to the public version, they leave the testing program and reinstall.

Firebase App Distribution

Firebase App DistributionFirebase App DistributionGoogle's service for sending pre-release Android (and iOS) builds to testers.Open in glossary → sends builds directly to testers, without going through a store track. That makes it popular for very early builds, feature branches and debug builds.

Developers can upload APK files, which install directly, or AAB (Android App Bundle) files, which Firebase delivers through Google Play’s internal app sharing (that needs the Firebase project linked to Google Play). Firebase builds expire after 150 days.

Which channel would you use?

Match each situation with the channel that fits best.

• 1.Five QA engineers on your team need the new iOS build today. They all have App Store Connect accounts.

  Choose a channel…TestFlight internalTestFlight externalPlay internal testingPlay closed testingPlay open testingFirebase App Distribution

• 2.2,000 newsletter subscribers should try the iOS beta. You want to share one link.

  Choose a channel…TestFlight internalTestFlight externalPlay internal testingPlay closed testingPlay open testingFirebase App Distribution

• 3.Your 8-person QA team needs the Android build through the Play Store, minutes after upload, exactly like the store version.

  Choose a channel…TestFlight internalTestFlight externalPlay internal testingPlay closed testingPlay open testingFirebase App Distribution

• 4.300 invited customers from a Google Group should test the Android beta before it goes public.

  Choose a channel…TestFlight internalTestFlight externalPlay internal testingPlay closed testingPlay open testingFirebase App Distribution

• 5.Anyone who finds the app on Google Play should be able to join the beta.

  Choose a channel…TestFlight internalTestFlight externalPlay internal testingPlay closed testingPlay open testingFirebase App Distribution

• 6.Two testers need a debug APK from a feature branch, without uploading it to the Play Console.

  Choose a channel…TestFlight internalTestFlight externalPlay internal testingPlay closed testingPlay open testingFirebase App Distribution

Check answers Reset0/6 answered

Environment builds: dev, staging, prod

Teams often build the same app version for different environmentsEnvironmentA setup of servers, data and configuration where the software runs, such as dev, staging or production.Open in glossary →:

Build	Talks to	Usually looks like
Dev	Developer or test servers, often unstable	Icon with “DEV” badge, name “FreshCart DEV”
Staging	stagingStagingA pre-release environment that mirrors production as closely as possible.Open in glossary → servers that copy production, with test data	Orange “STG” badge, staging banner in the app
Production	Real productionProductionThe live environment that real users use.Open in glossary → servers, real money	The real icon and name, like the store version

Different icons and names let you install several versions side by side and tell them apart at a glance. But they also cause classic mix-ups:

• A tester reports “test promo banner on the home screen”, but it’s staging content, not an app bug.
• A bug is “fixed” on staging but still happens on production, because the fix was on the server and wasn’t deployed there yet.
• A tester uses a production build with a test card and the payment fails, because production rejects test cards.

Always know which build you’re testing

Before you report or retest anything, check three things:

1. Version and build number, for example 2.4.0 (318). Good apps show it in Settings › About; TestFlight and App Tester show it too. On Android you’ll find it in Settings › Apps › [app].
2. Environment (dev, staging or production). Look at the icon, the app name, a banner, or the About screen.
3. How you got it (TestFlight, Play internal track, Firebase), and whether it was a fresh install or an update.

Then copy them into every bug reportBug reportA clear written description of a bug so developers can reproduce and fix it.Open in glossary →. See Writing bug reports and the version numbers section of Install, Update and Uninstall.

Try it: install a beta and report against it

Your phone has an older build of FreshCart installed. Pick the newest build in the TestFlight mock, read what to test, install it and follow the task. The About screen is behind the gear icon.

9:41

Apps

FreshCart

FreshCart Ltd.

INSTALL

Version 2.4.0 (318)

Expires in 88 days

What to Test

• • New: Apple Pay at checkout. Please pay for a test order end to end.
• • Fixed BUG-412: expired coupon codes were accepted.
• • Fixed BUG-398: order history empty after login.

Builds

• 2.4.0 (318)Expires in 88 days
• 2.4.0 (317)Expires in 85 days
• 2.3.2 (309)Expires in 61 days · Installed
• 2.3.1 (301)Expired

TestFlightFreshCart

Your task

1. In TestFlight, read the What to Test notes of the newest build.
2. Install it, then open FreshCart.
3. Do what the notes ask: pay with Apple Pay. Something is wrong.
4. Check Settings › About and fill in your bug report.

Bug not reproduced yet.

Bug report

Apple Pay sheet shows €0.00 instead of the order total

BuildChoose…Latest2.4.0 (318)2.4.0 (317)2.3.2 (309)2.3.1 (301)EnvironmentChoose…StagingProduction

Check report

When a new build arrives

A new build in TestFlight or App Tester is your cue for a small routine:

Practical exercise: plan your retests

FreshCart 2.4.0 (318) just arrived. Read the release notes, look at each bug in the tracker, and decide what to do with it on this build. Watch for fixes that aren’t in this build, reports from old builds, known issues and environment confusion.

STAGING

FreshCart 2.4.0 (318) has arrived in TestFlight

What to Test

• • New: Apple Pay at checkout
• • Fixed BUG-412: expired coupon codes were accepted
• • Fixed BUG-398: order history empty after login
• • Known issue: BUG-420 receipt colors are wrong in dark mode (fix planned for 319)
• • This build uses the staging server and its test content

Your bug tracker shows these six bugs. For each one, decide what you do with this build.

• 1.BUG-412 Expired coupon code is accepted at checkout

  Reported on 2.3.2 (309)Status: Ready for QAFix version: 2.4.0 (318)

  Decide…Retest the fix nowFix not in this build: waitKnown issue: don’t re-reportEnvironment mix-up: check productionOld report: reproduce on 318

• 2.BUG-405 App crashes when you cancel Apple Pay

  Reported on 2.4.0 (317)Status: Ready for QAFix version: 2.4.0 (319)

  Decide…Retest the fix nowFix not in this build: waitKnown issue: don’t re-reportEnvironment mix-up: check productionOld report: reproduce on 318

• 3.Receipt screen text is unreadable in dark mode

  Found by you today on 2.4.0 (318)

  Decide…Retest the fix nowFix not in this build: waitKnown issue: don’t re-reportEnvironment mix-up: check productionOld report: reproduce on 318

• 4.BUG-431 Home banner says "TEST PROMO, do not ship"

  Reported on 2.4.0 (318) · StagingStatus: Open

  Decide…Retest the fix nowFix not in this build: waitKnown issue: don’t re-reportEnvironment mix-up: check productionOld report: reproduce on 318

• 5.BUG-377 Search finds nothing for "oat milk"

  Reported on 2.2.0 (260)Status: Open

  Decide…Retest the fix nowFix not in this build: waitKnown issue: don’t re-reportEnvironment mix-up: check productionOld report: reproduce on 318

• 6.BUG-398 Order history is empty after logging in

  Reported on 2.3.2 (309)Status: Ready for QAFix version: 2.4.0 (318)

  Decide…Retest the fix nowFix not in this build: waitKnown issue: don’t re-reportEnvironment mix-up: check productionOld report: reproduce on 318

Check answers Reset0/6 answered

Common mistakes

#	Mistake	What happens	Typical severity
1	Testing an old build	Fixed bugs “still fail”, new features “are missing”	High (wasted time, wrong reopen)
2	“Build: latest” in reports	Developer can’t tell which code you tested	Medium
3	Retesting before the fix is in the build	Bug reopened although the fix was never delivered	Medium
4	Staging vs production mix-up	Test data or server-only issues reported as app bugs	Medium
5	Ignoring release notes	Known issues re-reported as duplicates; changed areas not tested	Low–Medium
6	Bug reported on an expired build	Nobody can install that build to reproduce it	Low
7	Only testing fresh installs of betas	Upgrade bugs from the store version are missed	High

Tools and how-to

TestFlightGoogle PlayFirebase

As a tester

1. Install TestFlight from the App Store.
2. Open the invitation email (or public link) and tap View in TestFlight, then Accept and Install.
3. Open the app from TestFlight or the home screen; beta apps have an orange dot next to their name.
4. Feedback: take a screenshot in the beta app › tap the preview › Share Beta Feedback. Or open TestFlight › the app › Send Beta Feedback.
5. Older builds: TestFlight › the app › Previous Builds.

The team uploads builds from Xcode (Product › Archive › Distribute App) or a CI pipeline, then adds testers and “What to Test” notes in App Store Connect › TestFlight.

As a tester

1. Open the opt-in link the team sends you and tap Become a tester (use the Google account that’s signed in to Play on your phone).
2. Install or update the app from the Play Store. It can take a little while to show up the first time.
3. To leave, open the same link and choose to leave the program, then reinstall the store version.

The team uploads an AAB in Play Console › Testing › Internal testing / Closed testing / Open testing and manages tester lists there. For quick one-off builds there’s also internal app sharing, which gives a download link per upload.

As a tester

1. Accept the email invitation.
2. Android: install App Tester, sign in with the invited Google account, and allow Install unknown apps for it when asked. iOS: follow the steps to register your device and add the App Tester web clip.
3. Pick a build in App Tester, read its notes and tap Download/Install.

The team uploads builds in the Firebase console › App Distribution, with the Firebase CLI (firebase appdistribution:distribute) or Gradle/fastlane plugins, and picks testers or tester groups for each release.

Example test cases

Checklist

New beta build checklist

0 of 9 checked

Copy

• Read the release notes: new features, fixed bugs, known issues, environment
• Installed the new build (not left on the previous one)
• Confirmed version, build number and environment in the About screen
• Ran a quick smoke test of the main flows
• Retested only bugs whose fix version matches this build
• Did not re-report known issues listed in the notes
• Checked staging-only content or data before reporting it as an app bug
• Tested at least one upgrade from the current store version
• Every new bug report has version, build, environment, device and OS

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.A developer says a bug is fixed, but it still happens on your phone. What should you check first?

   AWhether your phone needs a restartBWhich build is installed, and whether the fix is in that buildCWhether the developer tested itDThe phone's battery level

2. 2.What happens to a TestFlight build after 90 days?

   AIt becomes the App Store versionBIt expires and can no longer be openedCIt turns into an external buildDNothing

3. 3.Your Android QA team needs a build through the Play Store within minutes of upload. Which track fits best?

   AOpen testingBClosed testingCInternal testingDProduction

4. 4.Why does Android ask you to allow "Install unknown apps" for Firebase App Tester?

   ABecause the build is brokenBBecause App Tester installs apps from outside Google PlayCBecause you have no storageDBecause the app is for iOS

5. 5.A staging build shows a "TEST PROMO, do not ship" banner. What is the best next step?

   AReport a critical bug immediatelyBCheck whether the banner is staging test content before reporting it as an app bugCUninstall the appDIgnore everything on staging

Key takeaways

• Beta distribution gets real builds onto real phones before a release: TestFlight for iOS, Play testing tracks and Firebase App Distribution for Android.
• TestFlight: internal (team, up to 100, no review) vs external (up to 10,000, email or public link, Beta App Review). Builds expire after 90 days.
• Play tracks: internal (fast, small team), closed (invited group), open (anyone). Firebase sends builds directly, via App Tester.
• Dev, staging and production builds look different on purpose. Always know which environment you’re on.
• Before every report or retest, check version, build number and environment in the About screen.
• New build routine: read notes → install and confirm → smoke test → verify fixes → test new features → regression.