Your build is sitting in App Store Connect with status Ready to Test. You attached it to your external testing group. The tester confirms they got and accepted the email invitation. They open the TestFlight app on their iPhone — and your app isn’t in the list. Or they see your app but the build version listed is the previous one, not the new one you uploaded yesterday. You can’t reproduce this on your own device because you, naturally, see the latest build. The tester is stuck and so is your test cycle.
“Build not showing in TestFlight” is almost never a broken build. It’s almost always one of four things: group attachment, device compatibility (iOS version, hardware), Apple ID mismatch between invite email and TestFlight sign-in, or the tester didn’t complete the install flow inside the TestFlight app. Walking through the right checklist fixes 95% of cases without re-uploading anything.
Common causes
Ordered by hit rate.
1. Tester is in a group that doesn’t have this build attached
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 don’t see it.
How to spot it: App Store Connect → TestFlight → External Testing → for each group, check which builds are attached. The tester’s group must have the build.
2. Build’s minimum iOS version exceeds the device’s
Your build is compiled with IPHONEOS_DEPLOYMENT_TARGET = 17.0 (or you added an iOS 18 API), but the tester is on iPhone 8 running iOS 16. TestFlight filters the build out as incompatible. Tester sees “No builds available.”
How to spot it: Check Settings → General → About → iOS Version on the device, compare against your Xcode project’s deployment target. Mismatch = filtered.
3. Device hardware excluded from supported devices
Your build’s UIRequiredDeviceCapabilities (Info.plist) or excluded architectures filter out older iPhones (e.g., requiring Metal 3, ARKit, Neural Engine). The tester’s hardware isn’t in the supported set.
How to spot it: Read Info.plist for UIRequiredDeviceCapabilities. If you see arm64 only and the tester has an older device that’s 32-bit-only (rare today), or if you require features the device lacks (gyroscope, metal), check.
4. Apple ID mismatch between invite and TestFlight sign-in
You invited tester@gmail.com. The tester accepted the invite, but signs into TestFlight on the device with tester@icloud.com (their personal Apple ID). TestFlight matches by Apple ID exactly; 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 against the email in your invitation.
5. Tester accepted invite via email but never tapped Install in TestFlight
The email “View in TestFlight” button takes them into the app. They see the app listing but never tap 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 in the list, and confirm whether there’s a blue Install button still showing.
6. Tester is using TestFlight on a Mac (Apple Silicon) and your iOS build doesn’t allow it
By default, iPhone apps 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 → iOS Availability on Mac. If “Not Available,” Mac testers can’t install.
7. Tester previously declined the invite
Some testers tap “Decline” or dismiss the TestFlight notification. The invite goes into a declined state, and the build doesn’t show up. They need a fresh invite.
How to spot it: App Store Connect → TestFlight → External Testing → click tester → check status. “Declined” means resend.
Information to collect
- The tester’s device model + iOS version (
Settings → General → About). - The tester’s Apple ID currently signed into the TestFlight app.
- The exact email invitation address you sent.
- Which TestFlight group the tester is in and which builds are attached to that group.
- Your build’s Minimum iOS Version and supported devices from Xcode.
Shortest path to fix
Step 1: Verify group → build attachment
In App Store Connect → TestFlight → External Testing → tester’s group:
- “Builds” tab should show the build you want them to test.
- If it’s missing, click ”+” → select the build → Save.
- For internal testers, TestFlight → Internal Testing → ”+” → select the build.
Step 2: Verify compatibility
Ask the tester to send Settings → General → About → iOS Version and the device model. Compare:
- Build’s
MinimumOSVersion≤ device iOS version. - Build’s supported devices include the model.
If you’re requiring iOS 17+ and the tester is on iOS 16, either drop the target or invite a tester on a newer device.
Step 3: Match Apple IDs
Ask the tester to open the TestFlight app → top-right avatar → confirm which Apple ID is signed in. If it doesn’t match the invitation email:
- Easiest fix: re-send the invitation to the Apple ID they’re using in TestFlight.
- Alternative: have them sign out of TestFlight and sign in with the invited email.
App Store Connect → TestFlight → External Testing → click tester → Resend Invitation.
Step 4: Push them to refresh and install
Have the tester:
- Open the TestFlight app on the device.
- Pull down to refresh the apps list.
- Look in both the main list and “Previous Builds.”
- Tap the app → tap blue Install button.
Step 5: Reset by removing and re-inviting
If steps 1-4 don’t work, remove the tester from the group, then re-add them. This forces a fresh invitation and clears any stale Decline state.
App Store Connect → TestFlight → External Testing → tester → ”…” → Remove → confirm. Then ”+” → add tester again.
Step 6: As a last resort, have them reinstall TestFlight
Delete the TestFlight app from the device. Re-install from the App Store. Sign in with the correct Apple ID. Accept the invite email link. The fresh install often clears whatever state was confusing TestFlight.
How to confirm the fix
- 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 banner.
- Apple ID and email checks all match.
- Group + build attachment verified in App Store Connect.
If it still fails
- Check Apple System Status for TestFlight outages — rare but real, especially during major OS releases.
- Have the tester send a screenshot of their TestFlight Apps list; sometimes you’ll spot something the tester missed (e.g., a “Previous Builds” tab they overlooked).
- Try adding the tester to a different group with the same build attached — sometimes a single group’s state is stale.
- Re-upload the build with a bumped build number; rarely necessary but breaks the deadlock when nothing else does.
Prevention
- Use the lowest reasonable
MinimumOSVersionunless your code genuinely needs a newer API. - Document each tester’s Apple ID at invite time in a
TESTERS.mdso you can verify mismatches later. - Use a single dedicated tester group for “production-like” testing, separate from internal testers and from QA.
- Send a one-line confirmation message (“you should see version 2.7 (48) — let me know if not”) after attaching each new build so testers actively confirm.
- Avoid recycling tester email addresses; once an email leaves a group, the invite state can persist in unexpected ways.