TestFlight Beta Testing for Games: Setup, Limits and Review

TestFlight beta testing is how you get an iOS game onto other people's iPhones and iPads before it hits the App Store. This guide walks through the setup for game developers step by step, explains the limits that trip people up (10,000 external testers, 90-day builds, TestFlight App Review), and shows how to turn a public link into a playtest that sends back useful feedback instead of silent installs.

If you also ship on Android, the companion guide is Google Play's 12 testers rule. For general remote testing setup across platforms, see remote playtesting.

What you need before you start

• An Apple Developer Program membership. Apple lists it at 99 USD per membership year (local pricing varies). TestFlight is included; there is no extra charge for testers, and testers install the free TestFlight app.
• A Mac with Xcode. Unity and Godot both export an Xcode project for iOS. You archive and upload from Xcode (or a CI service such as Xcode Cloud).
• An app record in App Store Connect with a bundle ID that matches your build.
• Test information filled in. Apple's TestFlight page says a beta app description and beta app review information are required before you can share with external testers. You also need a feedback email.
• Export compliance answers. App Store Connect asks about encryption when you upload. Answer it once and set the key in your Info.plist so you stop getting asked.

TestFlight limits game developers should know

These numbers come from Apple's TestFlight overview and help pages. Check them again before a big launch, since Apple updates them.

• Internal testers: up to 100. These are App Store Connect users on your team with a role such as Admin, App Manager, Developer or Marketing. Internal builds don't need review, so they are available within minutes of processing.
• External testers: up to 10,000 per app. Anyone with an email address or your public link.
• Build lifespan: 90 days. Apple says you can test a build for up to 90 days from upload. After that it stops opening for testers. A long beta needs a fresh upload at least every three months.
• Up to 100 builds shared, and testers can install on up to 30 devices.
• Review submissions: up to six builds for TestFlight App Review in 24 hours, and only one build of each version in review at a time.

Internal vs external testing: which group to use

Internal testing is for you, co-developers and anyone you are happy to add to your App Store Connect team. It's the fastest way to check that a build installs and launches on real devices. Use it for every build before it goes external.

External testing is for everyone else: friends, your Discord, players who signed up from your website. Apple requires you to create an internal group before you can create an external one. Builds sent to external groups go through TestFlight App Review first.

One trap: builds uploaded from Xcode as TestFlight Internal Only can only be added to internal groups. If your external group says no builds are available, check this first.

Set up TestFlight beta testing step by step

Step 1: Upload the build

Archive in Xcode and upload to App Store Connect. Processing usually takes a few minutes to an hour. Keep the same version number (for example 0.9.0) and bump only the build number for each new upload during a beta round; this matters for review times, covered below.

Step 2: Create an internal group and test it yourself

In App Store Connect, open your app, go to the TestFlight tab and add an internal group. Install the build on at least one older device you plan to support. Check the first launch, the save system, audio on and off, and that your in-game feedback or bug button works.

Step 3: Create an external group

Under External Testing, click the add button, name the group (for example "Beta round 1") and add your build. Apple asks for What to Test text at this point. This is the most useful field in TestFlight and most developers waste it. More on that below.

You can tick Automatically notify testers so the build goes out the moment it is approved. Then click Submit Review.

Step 4: Wait for TestFlight App Review

Apple's overview says the first build added to an external group goes to review, and later builds of the same version may not need a full review. How long it takes varies:

• A PTKD Journal write-up on review waits puts the normal range at a few hours to 48 hours for the first build of a version, while noting that many 2026 submissions took two to seven days.
• In a March 2026 r/iosdev thread, one developer said it "takes a few hours and isn't a full review"; another waited three days, then saw later builds approved instantly. A June 2026 thread describes a first build sitting in Waiting for Review for a full week.

So: submit your first external build at least a week before the date you promised testers. After the first approval, keep the version number fixed and bump the build number. If you are well past 48 hours, contact App Review rather than cancelling and resubmitting, which restarts the queue.

To get approved first time, fill in every test information field, add a demo account if your game has a login, and make sure the build doesn't crash on launch. One r/iosdev developer said they passed with the app about 70% done, as long as the core and onboarding worked.

Step 5: Invite testers

You have two options, and you can use both.

• Email invites. Add testers by email or import a CSV. You see their name, install date, sessions and crashes. Best for a small, known group.
• Public link. Click Create Public Link under the group's Testers tab. Choose Open to Anyone or Filter by Criteria, where you can require device types and OS versions. Under Tester Limit you can cap joins anywhere from 1 to 10,000.

Public link testers show as anonymous in App Store Connect, though you still see installs, sessions and crashes. Apple also warns that anyone can share the link, so treat it as semi-public. If your game is under wraps, use email invites only.

Set criteria that match your build. If your game needs iOS 17 or a device with a certain chip, filter for it. Otherwise testers with unsupported devices join, see no compatible build, and leave.

Write What to Test like a playtest brief

Testers see your What to Test text inside the TestFlight app every time a build arrives. Most games put "Bug fixes" there. Treat it as your playtest brief instead.

Build 0.9.0 (14). Please play for about 20 minutes. We're testing: the first three levels and whether the swipe controls feel right. Please tell us: 1. Where did you first feel stuck or confused? 2. Did any swipe not do what you expected? Which one? 3. Would you play level 4 tomorrow? Why or why not? Known issues: no music in level 3 yet, the shop is placeholder. Send feedback by taking a screenshot in the game, or use [your survey link].

Keep it short. Change it every build so testers know what's new. Questions about specific moments work far better than "any feedback?". Our playtest survey questions guide has more you can borrow.

Collecting feedback from TestFlight testers

TestFlight's built-in feedback is better than many developers realise:

• Testers on TestFlight 2.3 or later can take a screenshot inside your game and send it with a comment. They can mark it up.
• When the game crashes, TestFlight offers to send a crash report, and the tester can add context.
• You see all of it in the TestFlight Feedback section of App Store Connect, filterable by platform and OS version.
• Testers on tvOS or older iOS versions send feedback to the email address you gave in test information.

What TestFlight won't tell you is why a player stopped. Sessions and crash counts show that someone quit after four minutes; they don't show what confused them. For that you need either a short survey or a recorded session. iOS has built-in screen recording with microphone audio (long-press the record button in Control Center), and our remote playtesting guide explains how to ask for a recorded run with consent.

A simple feedback setup for an indie game

1. TestFlight screenshots for bugs and visual issues.
2. A 5-question form linked in What to Test for opinions. A ready-made one is in our game feedback form template.
3. One channel (Discord or email) for questions.
4. A recorded session from two or three testers per round if you can get them.

Running a TestFlight beta round

Here's a two-week round that works for most small mobile games. For the full plan behind it (goals, exit criteria, welcome and closing messages), see our beta testing checklist.

• Day 1: Build to internal group. Fix anything that blocks launch.
• Day 2: Submit to external group review. While you wait, line up testers.
• Approval day: Invite the first 20 to 50 testers. Watch crash counts for 24 hours.
• Day 3 to 7: Read feedback daily. Reply to testers who sent screenshots. Ship one fixed build mid-week with an updated What to Test.
• Day 8 to 14: Open the public link wider if the build is stable. Run your end-of-round survey.
• End: Expire the build if you don't want it played after the round. Apple notes that if you don't expire a build, invited testers can keep using it even after your game is live on the App Store.

Write up what you learned in one page; the playtest report template is built for that.

Common TestFlight problems and fixes

• "No builds available" for external testers. The build hasn't been added to that group, is still waiting for review, was uploaded as Internal Only, or doesn't match the public link criteria. Apple's insight cards at the top of the group page flag missing compatible builds, a full public link, and builds about to expire.
• Waiting for review for days. Normal for a first build of a new version in 2026. Keep the version number and bump the build number for later uploads.
• Testers say the build won't open. It probably passed 90 days. Upload a new build.
• Testers installed but nobody sent feedback. Your What to Test probably didn't ask anything. Ask two or three specific questions and remind testers once mid-round.
• Public link full. Raise the tester limit or disable the link so people stop trying to join.
• Testers who don't play your genre. A link posted to a general forum fills with people who wanted a free game. Filter where you post, and recruit people who play games like yours.

Finding TestFlight testers who will actually play

The public link is easy to create; finding people who install and then send something back is the hard part. Good sources:

• Your own players: newsletter, Discord, social posts with a short clip.
• Genre communities that allow beta posts (check the rules). Our list of where to post your game for feedback quotes current rules for each.
• A playtest swap with another mobile developer, where you test each other's builds.

You can also post your TestFlight playtest on Get Playtests for free. TestFlight links go live right away, you choose the focus areas you want covered, and players who picked your game send written, video or livestream reviews. No credit card, and you can show the link only to reviewers who have claimed your playtest, so it doesn't spread across the internet. A brand-new developer's first posting may wait until one of their reviews of someone else's game is approved; that's how every game on the site keeps getting reviews.

Common questions

Is TestFlight free?

TestFlight itself is free for developers and testers, but you need an Apple Developer Program membership to upload builds.

How many testers can I have on TestFlight?

Up to 100 internal testers and up to 10,000 external testers per app.

How long does a TestFlight build last?

90 days from upload. After that, testers can't open it.

Do I need review for every build?

The first build of a version needs TestFlight App Review for external testing. Later builds of the same version often don't need a full review.

Where does TestFlight feedback go?

To you, in the TestFlight Feedback section of App Store Connect: screenshots with comments, crash reports with tester notes, and any written feedback. Testers on tvOS or older iOS versions send it to the feedback email you set in test information.