TestFlight: Test Your iPhone App Before Submitting

What is TestFlight and what is it for?

TestFlight is Apple's service that lets you install your app on real iPhones before it launches on the App Store. You upload a build to App Store Connect, invite testers, and they install it with the TestFlight app, which is free on the App Store. There are two kinds of testers: internal testers, up to 100 members of your team, with no Apple review; and external testers, up to 10,000 people, invited by email or public link, after a beta review of your first build. Each build stays testable for 90 days.

Criterion	Internal testers	External testers
Maximum number	100	10,000
Access to your account	Yes, with a role	No
Invitation	Added to the internal group	Email or public link
Apple beta review	None	On the first build
Who it's for	You, a partner, someone close	Friends, early users

To use TestFlight, you need a paid Apple Developer account: the service isn't available with a free account. The rest of this guide assumes you have one, under the standard program: Apple's Enterprise program doesn't give you access to TestFlight.

On my apps, every build uploaded with EAS Submit goes through TestFlight and through my iPhone before it's sent to review. That's where I find the problems you can't see in development.

Uploading a build to TestFlight

A build is a compiled, signed version of your app: if it's signed wrong, Apple rejects it on upload with ITMS-90034. For it to show up in TestFlight, you have to upload it to App Store Connect. With Expo, that's eas build --platform ios then eas submit --platform ios, with a recent enough build image to avoid ITMS-90725. According to Expo's documentation, the build appears in TestFlight once Apple has processed it, usually in 10 to 15 minutes. You can do all of this from a PC: the guide publish an iOS app without a Mac walks through the whole pipeline.

Two details often trip people up the first time:

• The build number has to change with every upload. Apple rejects two builds with the same number for the same version. With EAS, turn on auto-increment and you'll never think about it again.
• The encryption question. Until you answer the question about encryption usage, the build stays stuck with a missing compliance status. You can answer it every time in App Store Connect, or declare it once and for all in your app's config.

Internal testers: your team, no waiting

Internal testers are users of your App Store Connect account with an assigned role. Apple allows up to 100, and each one can install the app on multiple devices, up to 30.

Their big advantage: no beta review. As soon as the build has finished processing, with no automatic error like ITMS-90717, you add it to your internal group and it's available. This is the right group for you, and for a partner or someone close you give access to your account.

Their limit: you have to add them as users of your App Store Connect account. Not a good fit for strangers.

External testers and beta review

External testers don't need any access to your account. You can invite up to 10,000, by email or public link. This is the right group for friends, early users, a community.

In return, Apple checks the build before opening it to them. When you add the first build of a version to an external group, it goes into beta review. Later builds of the same version don't necessarily need a full review.

Before that submission, App Store Connect asks you for test information:

• a beta description, telling testers what to look at;
• a feedback email address;
• your contact details, so Apple can reach you.

Beta review isn't App Store review. A build accepted in TestFlight can still be rejected at publication.

Beta review checks that the build follows the rules, but the final review also looks at your listing, your subscriptions, your legal texts and the full experience. Keep the classic rejection reasons in mind, covered in why Apple rejects an app.

Inviting testers with a public link

The public link is the easiest way to get people you don't know yet to test your app. Here's Apple's procedure, with the interface labels:

1. In App Store Connect, open your app, then the TestFlight tab.
2. Under External Testing, select your external group.
3. Click Create Public Link.
4. Choose Open to Anyone to open the link to everyone, or Filter by Criteria to limit it to certain devices and iOS versions.
5. If you want, set a tester limit with Set Limit.

Then share the link wherever you like: message, social media, email. The person installs the TestFlight app, opens the link and accepts the invitation.

Two things to know before sharing it widely:

• Set a limit. If your link spreads more than expected, you'll stay in control of the number of testers.
• Public link testers are anonymous. For them, App Store Connect only shows the install date, sessions and crashes. If you want to know who tested what, invite by email instead.

How long does a TestFlight build last?

A build stays available to testers for 90 days. After that, it expires and your testers can't open it anymore. If your beta runs longer, just upload a new build before the deadline.

In practice, you'll upload new builds much more often: with every significant fix. Each new build added to the group is offered to your testers, who get it in the TestFlight app.

Collecting tester feedback

TestFlight has a built-in feedback system: the tester takes a screenshot in your app, can annotate it, and sends it to you. If the app crashes, you get a crash report, and the tester can add context. You'll find everything in App Store Connect.

It's useful, but it's not enough to understand a specific crash. On my apps, I add Sentry, which reports the error with the offending line of code, and PostHog, which shows where users drop off. Both work in a TestFlight build just like in production.

Testing subscriptions in TestFlight

If your app sells a subscription, TestFlight is where you check that it really works. Purchases made in a TestFlight build go through Apple's test environment: your testers aren't charged. Renewals are accelerated: each subscription renews once a day, up to six times over a week, whatever its actual duration.

At a minimum, check that the displayed prices are right, that the purchase actually unlocks the app, and that the restore button recovers the subscription after a reinstall. I use RevenueCat to manage subscriptions in my apps; the whole setup, from App Store Connect products to the paywall, is described on the iOS in-app subscriptions page.

What to test before submitting to Apple

This is the list I go through before every review submission. Each item matches a rejection reason or an avoidable crash.

The first launch

• Delete the app, reinstall it from TestFlight, open it. That's what the reviewer will do.
• Go through the whole onboarding, without skipping anything.
• Deny every permission (notifications, camera, location) and check that the app keeps working.

The money

• The paywall shows the prices, the duration, and links to the terms of use and privacy policy.
• The purchase works, and so does restore.
• All configured products are visible to the reviewer: guideline 2.1 requires in-app purchases to be complete, visible and functional.

Tough conditions

• Airplane mode and a slow network: a clear message, not a blank screen.
• The smallest iPhone you support and the largest: nothing cut off, nothing hidden by the keyboard. A screen cut off on a small iPhone got me a rejection on Solys.
• Long text, if your app is translated.

The package for the reviewer

• If your app requires sign-in, a demo account in the review notes, with your backend running. Guideline 2.1 explicitly asks for it.
• Review notes that explain in two sentences what the app does and where to find the main feature.

If your app still gets rejected, the app rejected by Apple page explains how to respond without losing a week. And for the big picture of publishing, from listing to launch, read publish an app on the App Store.

A test sheet to fill in on your build

Download the 16-scenario sheet in CSV format. It separates the setup, the action to perform, the expected result and the observed evidence. Import it into Numbers, Excel or Google Sheets, then fill in the version, the device and the result of each run.

For a fictional reading log app, "save a page" isn't enough: enter page 24, fully close the app, relaunch it and find the value again. A test that hasn't been run stays "To test". If your app has no subscription, mark the purchase scenarios "Not applicable", with that reason.

The sheet is a starting point to adapt, not a certification. You'll also find App Review notes and the other free templates to explain to the reviewer the flow you actually checked.

Going from TestFlight to the App Store

TestFlight is the step where your app becomes real: it runs on a real iPhone, in real people's hands. In the iOS Kit path, it's the second step: build the core of the app and test it on your iPhone with TestFlight, before wiring up subscriptions and then preparing for publication.

After TestFlight comes Apple's review: the Apple Review Kit brings together my pre-submission checklist and the notes for the reviewer. The homepage shows the four steps to build your mobile app with Claude Code.

Nobody can guarantee Apple will accept your app: Apple decides.

Frequently asked questions

How do I test my iPhone app with TestFlight?

Upload a build to App Store Connect, then add it to a tester group. With Expo, you compile it with EAS Build and upload it with EAS Submit: it appears in TestFlight once Apple has processed it, usually in 10 to 15 minutes according to Expo. Your testers install it with the TestFlight app, free on the App Store. You need a paid Apple Developer account.

How do I create a TestFlight link to invite testers?

In App Store Connect, open your app's TestFlight tab, select your group under External Testing and click Create Public Link. Choose Open to Anyone or Filter by Criteria, then set a limit with Set Limit. Public link testers stay anonymous: if you want to know who tested what, invite them by email instead.

Does TestFlight beta review replace App Store review?

No. Beta review checks that the build follows the rules, but the final review also looks at your listing, your age rating, your subscriptions, your legal texts and the full experience. So a build accepted in TestFlight can still be rejected at publication. Only external testers trigger a beta review, on the first build of a version: internal testers don't go through any.

How many testers can you invite on TestFlight?

You can invite up to 100 internal testers and up to 10,000 external testers. Internal testers are members of your App Store Connect account, with no beta review, and each can install the app on up to 30 devices. External testers are invited by email or public link, after a beta review of the first build. Each build stays testable for 90 days.

Can you test a subscription in TestFlight without being charged?

Yes, purchases made in a TestFlight build go through Apple's test environment: your testers aren't charged. Renewals are accelerated: each subscription renews once a day, up to six times over a week, whatever its actual duration. At a minimum, check the displayed prices, that the app unlocks, and restore after a reinstall. The full setup is described on iOS in-app subscriptions.

What should you check in TestFlight before submitting the app to Apple?

Reinstall the app from TestFlight, like the reviewer will, and go through the whole onboarding. Deny every permission, test purchase and restore, then try airplane mode and the smallest and largest iPhones you support. If the app requires sign-in, set up a demo account in the review notes, with your backend running.