Skip to content

How-to guide

Showing the app to the client before release

TestFlight's two distinct groups, the fact that external testing goes through its own review, and why internal testing breaks the closed-testing requirement.

Written for: Teams who need to show the app to a client or team before it goes liveLast updated: 6 min read

In short

How do you show an app to a client before publishing it?

Before release, an app is shown through TestFlight on iOS and Play Console's testing tracks on Android. On TestFlight, internal testing runs immediately with team members; external testing goes through a separate beta review and needs approval. On Android, internal testing distributes instantly, but a user opted into the internal test cannot join a closed test — a critical distinction on accounts subject to the closed-testing requirement.

Why do the routes differ on iOS and Android?

Both stores offer pre-release distribution, but differently. On Apple, TestFlight is the single tool and splits into two groups: team members and external testers. On Google there are three separate testing tracks — internal, closed and open — and they exclude one another.

In practice the decisive difference is review. Distributing outside the team on TestFlight requires the build to pass beta review; on Play, internal testing distributes immediately. So the answer to “can we show it today” depends on the platform.

Searches this page answers

  • how to use testflight
  • show app before publishing
  • play console internal testing
  • testflight external testing review
  • distribute app beta to client
  • share app with client before launch

The Android trap: internal testing breaks closed testing

Play's three tracks exclude one another: a user opted into your app's internal test cannot join an open or closed test without leaving it. Normally harmless — but if your account is subject to the closed-testing requirement, it hits you directly.

The common sequence of error: the team adds itself to internal testing for a quick look, then invites the same people to the closed test while gathering twelve testers, and the invitations do not appear. Finding out why takes days. If closed testing is ahead of you, put the team into the closed test from the start and use internal testing only for build verification.

Which route for which purpose
PurposeiOSAndroid
Show the team todayTestFlight internalInternal test
Show the clientTestFlight external (beta review)Closed test
Run a wide betaTestFlight externalOpen test
Meet the 12-tester requirementNo equivalentClosed test only

Turn TestFlight off before a transfer

If the app is moving to another developer account, TestFlight beta testing must be turned off for all beta versions before the transfer. An active beta is one of the conditions under which Apple blocks a transfer, and it is usually discovered on the day the transfer is attempted.

The same ordering logic applies at handover: turning testing off, transferring the account and completing the payment setup happen in sequence. Teams that do not know the order spend handover day on three separate waits.

Sources

  1. 01TestFlight — beta testing for App Store appsApple · 2026
  2. 02Set up an open, closed, or internal testGoogle Play Console Help · 2026
  3. 03App transfer criteria — App Store ConnectApple · 2026

Frequently asked

Questions we get asked

Get in touch

Yes, and that is the surprising part. Distributing to people outside the team on TestFlight requires the build to pass beta review; that review is separate from the release review but is still a wait. Put the step in the calendar before telling a client “we'll show you tomorrow”. Internal testing, on the other hand, runs immediately with team members — the right route when you need to show something fast.

It depends on the purpose. To show the team quickly, internal testing — instant distribution, up to a hundred people per app. To show a client or a selected group, closed testing — managed by email list or Google Group. But if your account is subject to the closed-testing requirement there is a trap: a person opted into the internal test cannot join the closed test without leaving it, so you cannot add your team internally and then count them toward the twelve.

In writing, with a defined scope. “I looked, it's nice” is not sign-off; which flows were tried on which device, and what is accepted, should be written down. The practical method is to send a short acceptance list with the test build: each item a user flow, each with a checkbox. That list both documents the approval and makes the client actually walk through the app — most late feedback comes from screens nobody opened.

Guides

Let's walk these steps together

We can stand alongside you while you apply any of this to your own project.

Book a callinfo@neuros.com.tr