TestFlight and Internal Testing: Getting Builds to Clients Fast

"Can I see it on my phone?" is the most useful question a client or product owner can ask during a project, and the answer should be "yes, in a few minutes". Screenshots and screen recordings hide problems that are obvious the moment someone holds the real app: a button under their thumb, a slow screen on their older Android phone, a word that wraps badly in their language.

This guide covers every practical way to get React Native test builds onto real phones in 2026: TestFlight for iOS, Google Play's testing tracks, Expo's internal distribution, and over-the-air previews for quick changes, with what each is best for.

Key takeaways

• TestFlight internal testing gets iOS builds to up to 100 members of your App Store Connect team, usually right after processing.
• TestFlight external testing reaches up to 10,000 people by email or public link, after a short Beta App Review for the first build of a version.
• Google Play's internal testing track reaches up to 100 testers quickly; closed and open tracks scale further.
• EAS internal distribution shares installable builds by link, without either store, which is ideal for early client demos.
• Over-the-air updates to a preview channel deliver JavaScript changes to testers in minutes, without a new build.

The options at a glance

TestFlight on iOS

Upload a build to App Store Connect (for example with EAS Submit), wait for processing, then:

• Internal testers are people on your App Store Connect team. Add them to a group and they can install the build through the TestFlight app straight away.
• External testers don't need an App Store Connect account. Invite them by email or share a public link. The first build of each version goes through a short Beta App Review before external testers can install it.

Builds expire after 90 days. Testers can send feedback with screenshots from inside the TestFlight app, and crash reports appear in App Store Connect, which makes TestFlight more than a delivery tool.

Google Play testing tracks

Play Console offers internal, closed and open testing tracks. For client and team testing, the internal testing track is the fastest: invite testers by email, share the opt-in link, and they install from the Play Store app like any other app.

Remember that new personal developer accounts must run a closed test with at least 12 testers for 14 days before getting production access, so a closed track often runs in parallel during development anyway.

EAS internal distribution: before the stores are set up

Early in a project, you may not have store listings yet, or you want a client to see the app this week. EAS can build installable test apps and share them by link or QR code:

• Android: an APK anyone can install from the link.
• iOS: an ad hoc build that installs only on registered devices. Register a tester's iPhone with eas device:create, which generates a link they open on the device, then rebuild so the device is included.

{
  "build": {
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    }
  }
}

Apple limits how many devices you can register per year, so use internal distribution for a small group and TestFlight once the circle grows.

Over-the-air previews: the fastest feedback loop

Once testers have a preview build installed, most changes are JavaScript. Publishing an update to the preview channel delivers it without a new build or store processing:

eas update --branch preview --message "Booking screen: new date picker"

Testers close and reopen the app to get it. For a weekly client demo, this means the build you show on Friday includes Thursday's fixes.

From the field: EAS builds, TestFlight, Play testing tracks and OTA updates are all part of the release path I own on the apps I ship. For clients, the habit that matters most is a build on their own phone every week, because that's where real feedback comes from.

A weekly rhythm that works

1. Monday to Thursday: merges to main publish OTA updates to the preview channel.
2. Native changes: a new preview build goes out the same day through internal distribution, TestFlight internal or Play internal testing.
3. Friday: a short demo call with the client using the build on their own phone, plus a written list of what changed.
4. Before release: a production build goes to TestFlight and Play internal testing for a final check on real devices.

Common problems testers hit

FAQ

How many testers can I add to TestFlight?

Up to 100 internal testers from your App Store Connect team, and up to 10,000 external testers by email or public link. External testing requires a Beta App Review for the first build of each version.

How do I share an iOS app without the App Store?

Use TestFlight, which is the standard route, or an ad hoc build that installs on registered devices, for example with EAS internal distribution. For businesses distributing apps to their own employees, Apple offers separate programs.

What's the fastest way to show a client a change?

If the change is JavaScript only, publish an over-the-air update to the preview channel their build listens to; they'll see it after reopening the app. For native changes, a TestFlight internal or Play internal testing build is usually available within the hour.

Do testers need an Apple account for TestFlight?

Testers need the TestFlight app and an Apple account on their device to install builds. External testers don't need to be part of your App Store Connect team; internal testers do.

Next steps

If your clients or product team still review your app through screenshots, I can set up a pipeline that puts a fresh build on their phones every week. Get in touch, or see my services.

Sources

• TestFlight, Apple
• Set up an open, closed or internal test, Google Play Console Help
• Internal distribution, Expo
• EAS Update introduction, Expo