Your build sits in App Store Connect with status Ready to Test. You attached it to an external testing group. The tester confirms they got the invite email and accepted it. They open the TestFlight app on their iPhone — and your app isn’t in the list. Or they see your app, but the version listed is the previous build, not the one you uploaded yesterday. You can’t reproduce this on your own device because you always see the latest build. The tester is blocked, and so is your test cycle.
Fastest fix: in App Store Connect → TestFlight → the tester’s group → Builds, confirm the new build is actually attached to that group, then have the tester open TestFlight, pull-to-refresh, and tap Install. That single check resolves the most common case. If it’s already attached, work down the table below.
“Build not showing in TestFlight” is almost never a broken build. It’s one of a handful of things: the build isn’t attached to the tester’s group, the build is still in Beta App Review, the tester wasn’t notified, device incompatibility (iOS version or hardware), an Apple ID / region mismatch between the invite and the TestFlight sign-in, or the tester never tapped Install inside the app. Walking the right checklist fixes the overwhelming majority of cases without re-uploading anything.
Which bucket are you in?
Use this to jump to the right section.
| Symptom the tester reports | Most likely cause | Section |
|---|---|---|
| App not in TestFlight list at all | Build not attached to their group, or invite/Apple-ID mismatch | 1, 5 |
| ”No builds available” under your app | iOS version too low, hardware excluded, or region mismatch | 2, 3, 6 |
| Sees an old build, not the new one | Build still in Beta App Review, or testers not notified | 4, 8 |
| Got the email but nothing installed | Never tapped Install, or declined earlier | 7, 9 |
| Mac tester sees nothing | iOS app availability on Mac turned off | 10 |
Common causes
Ordered by hit rate.
1. The build isn’t attached to the tester’s group
You have multiple TestFlight groups (Internal, External-QA, External-Public). You uploaded the new build and attached it only to External-QA. The tester is in External-Public, so they see nothing — or only the older build that group still has.
How to spot it: App Store Connect → TestFlight → sidebar → the tester’s group → Builds. The build you want them on must be listed there. Each group’s build list is independent.
2. The build’s minimum iOS version exceeds the device’s
Your build is compiled with IPHONEOS_DEPLOYMENT_TARGET = 17.0 (or you called an iOS 18-only API), but the tester is on an iPhone 8 running iOS 16. TestFlight filters incompatible builds out, and the tester sees “No builds available.”
How to spot it: ask the tester for Settings → General → About → iOS Version and compare it against your Xcode deployment target. Device iOS version below the build’s MinimumOSVersion = filtered.
3. The device hardware is excluded from supported devices
Your build’s UIRequiredDeviceCapabilities (Info.plist) filters out devices that lack a required feature — e.g. metal, gyroscope, arkit. The tester’s hardware isn’t in the supported set, so TestFlight hides the build.
How to spot it: read Info.plist for UIRequiredDeviceCapabilities. If you require a capability the tester’s device doesn’t have, it’s filtered. App Store Connect also shows the build’s supported-device list on the build’s detail page.
4. The build is still in Beta App Review (not yet approved)
External testing requires Apple’s Beta App Review for the first build of a version and for builds with significant changes. Until it’s approved, external testers won’t see it even though the build uploaded fine. Internal testers (your App Store Connect users) can test before review; external testers cannot.
How to spot it: App Store Connect → TestFlight → the build. If the status is In Review, Waiting for Review, or Rejected rather than Ready to Test / Testing, that’s why external testers don’t have it. Review for builds typically clears within about a day, but allow longer around major OS releases.
5. Apple ID mismatch between invite and TestFlight sign-in
You invited tester@gmail.com. The tester accepted, but signs into TestFlight with tester@icloud.com (their personal Apple ID). TestFlight matches an email invite to the Apple ID it was sent to; the invitation isn’t visible to a different ID.
How to spot it: on the device, TestFlight → top-right avatar → check the signed-in Apple ID. Compare it against the exact address in your invitation. A tester can only see an email invite under the Apple ID that received it.
6. Region / storefront or age-rating restriction
If your app’s availability is limited to certain regions, or the build carries an age rating the tester’s account doesn’t meet, the build can be filtered out for that tester’s App Store storefront even after they accept the invite.
How to spot it: App Store Connect → App Information / Pricing and Availability for region availability, and the build’s age rating. Confirm the tester’s device App Store region (Settings → [their name] → Media & Purchases → View Account → Country/Region) is one your app serves.
7. Tester accepted the invite but never tapped Install
The “View in TestFlight” / “Start Testing” button in the email opens the app. The tester sees the app listing but never taps Install, assuming acceptance was enough. The build is “available to test” but not actually installed.
How to spot it: ask the tester to open TestFlight, find your app, and confirm whether a blue Install button is still showing.
8. The build was attached but testers were never notified
When you add a build to a group, the Automatically notify testers checkbox controls whether testers get a push/email about it. If it was unchecked (or the build was added before approval), testers may never have been prompted and won’t think to look. The build still has to be installed manually inside TestFlight regardless.
How to spot it: App Store Connect → TestFlight → the build → check whether testers were notified. You can manually trigger it with Notify Testers after the build is approved.
9. Tester previously declined the invite
Some testers tap “Decline” or dismiss the TestFlight notification. The invite goes into a declined state and the build won’t show. They need a fresh invite.
How to spot it: App Store Connect → TestFlight → the group → click the tester → check status. Declined means resend or remove and re-add.
10. Tester is on an Apple Silicon Mac and your iOS build doesn’t allow it
By default, compatible iPhone/iPad apps can run on Apple Silicon Macs unless you opt out. If you opted out, Mac testers see nothing.
How to spot it: App Store Connect → Pricing and Availability → the iOS-app-on-Mac availability toggle. If it’s set to not available, Mac testers can’t install.
Information to collect
Before you change anything, get these from the tester (guessing here wastes a whole round-trip):
- Device model and iOS version (
Settings → General → About). - The Apple ID currently signed into the TestFlight app (top-right avatar).
- The exact email address your invitation was sent to.
- Which TestFlight group they’re in, and which builds are attached to that group.
- Your build’s
MinimumOSVersionand supported devices (Xcode / the build detail page).
Also confirm whether it’s failing for one tester or several. One tester points to a device, Apple ID, or region issue; several point to group attachment, review status, or notification.
Shortest path to fix
Step 1: Verify the group → build attachment
App Store Connect → TestFlight → sidebar → the tester’s group → Builds:
- The build you want them to test should be listed. If it’s missing, click Add Builds, select the build, and confirm.
- Alternatively, open the build itself (Builds → platform → the build), and next to Groups click the add button (+) to attach the group.
- For internal testers, attach the build to the Internal Testing group the same way.
Step 2: Confirm it’s past Beta App Review
Open the build in TestFlight. External testers only see a build once its status is Ready to Test / Testing. If it reads Waiting for Review, In Review, or Rejected, that’s the blocker — wait for approval (usually about a day) or fix the rejection. Internal testers can test while external review is pending.
Step 3: Verify compatibility
Ask the tester for Settings → General → About → iOS Version and the device model, then compare:
- Build’s
MinimumOSVersion<=device iOS version. - Build’s supported devices include the model.
If you require iOS 17+ and the tester is on iOS 16, either lower the deployment target or test on a newer device.
Step 4: Match Apple ID, region, and resend
Ask the tester to open TestFlight → top-right avatar → confirm the signed-in Apple ID. If it doesn’t match the invitation address:
- Easiest fix: resend the invitation to the Apple ID they actually use in TestFlight.
- Alternative: have them sign out of TestFlight (avatar → Sign Out) and sign in with the invited email.
Also confirm the device’s App Store region is one your app serves. To resend: App Store Connect → TestFlight → the group → click the tester → Resend Invitation.
Step 5: Make sure they were notified, then refresh and install
If the build was added with Automatically notify testers unchecked, click Notify Testers on the approved build. Then have the tester:
- Open the TestFlight app.
- Pull down to refresh the apps list.
- Check both the main list and Previous Builds.
- Tap the app, then tap the blue Install button.
Step 6: Reset by removing and re-inviting
If steps 1–5 don’t work, remove the tester from the group, then re-add them. This forces a fresh invitation and clears any stale Declined state.
App Store Connect → TestFlight → the group → the tester → remove → confirm. Then add the tester again.
Step 7: Last resort — reinstall TestFlight
Delete the TestFlight app, reinstall it from the App Store, sign in with the correct Apple ID, and accept the invite link again. A fresh install often clears whatever local state was confusing TestFlight.
How to confirm it’s fixed
- The tester sees your app and the new build version in their TestFlight app list.
- Tapping Install downloads and opens the build with the expected version/build banner (e.g.
2.7 (48)). - Apple ID, invitation email, and App Store region all match.
- Group + build attachment and Ready to Test status are verified in App Store Connect.
FAQ
How long after I attach a build should it appear for testers?
For external testers, only after the build passes Beta App Review — usually within about a day of submitting, longer around major OS releases. Once it’s Ready to Test and testers are notified, it should appear on a pull-to-refresh in their TestFlight app within minutes.
Why does the tester see “No builds available” even though the build is attached?
That message means TestFlight filtered every attached build out for that device — almost always a minimum-iOS-version or hardware-capability mismatch (sections 2 and 3), a region/storefront restriction (section 6), or the build isn’t yet approved for external testing (section 4).
Does the tester have to be on the exact Apple ID I invited?
Yes. An email invite is only visible under the Apple ID that received it. If they sign into TestFlight with a different Apple ID, resend the invite to that ID or have them switch (section 4 / Step 4).
How many testers can I have, and do builds expire?
As of June 2026, TestFlight allows up to 10,000 external testers and up to 100 internal testers (App Store Connect users) per app. A build is available for testing for up to 90 days from upload, after which it expires and must be replaced with a newer build.
The tester is on a Mac and sees nothing — is that normal?
Compatible iPhone/iPad apps run on Apple Silicon Macs by default, but you can opt out in Pricing and Availability. If you opted out, Mac testers can’t install — invite them on an iOS device instead (section 10).
If it still fails
- Check Apple’s System Status for a TestFlight outage — rare but real, especially during major OS releases.
- Have the tester screenshot their TestFlight Apps list; you’ll often spot something they missed (a Previous Builds tab, the wrong Apple ID).
- Add the tester to a different group with the same build attached — a single group’s state is occasionally stale.
- Re-upload with a bumped build number. Rarely necessary, but it breaks the deadlock when nothing else does.
Prevention
- Use the lowest reasonable
MinimumOSVersionunless your code genuinely needs a newer API. - Record each tester’s Apple ID at invite time (a
TESTERS.mdin the repo works) so you can verify mismatches later. - Keep one dedicated “production-like” external group, separate from internal testers and QA, so build attachment is unambiguous.
- Leave Automatically notify testers checked, and send a one-line confirmation after each new build (“you should see version 2.7 (48) — tell me if not”) so testers actively confirm.
- Don’t recycle tester email addresses; once an email leaves a group, the invite state can persist in unexpected ways.