TestFlight Feedback: Finding and Reading It

TestFlight feedback is the set of screenshots, comments and crash reports that beta testers send from inside your build, and it lands in App Store Connect under the TestFlight tab, in the Feedback section of the sidebar. Apple says feedback from testers running TestFlight 2.3 or later appears there, that crash reports can be downloaded for 120 days, and that you can have it pushed to your own server. On an app you inherited, the useful question is whether anyone has opened that section in the last year, because it is often the cheapest source of real device data you already own.

The pages that rank for this topic mostly answer one of two questions. Apple’s documentation explains the buttons for a developer who is setting up beta testing for the first time, and the forum threads answer a tester asking where the feedback button went. None of the ones I read covers the situation that brings an engineering lead here, which is taking over a project whose beta program was run by someone else and working out what the feedback pipeline is actually doing. This article covers that, using Apple’s current App Store Connect help and TestFlight overview, and it flags the places where the documentation says nothing so you can check them on your own account.

Where does TestFlight feedback appear in App Store Connect?

It appears in the TestFlight tab of your app, in the sidebar under a heading called Feedback, with two entries: Screenshots and Crashes. Click Screenshots and you see the screenshots testers took together with their comments. Click Crashes and you get a table of submission times and crash details. Apple lists the required role as Account Holder, Admin, App Manager, Developer or Marketing, so most people with a login to the app can read it.

There is a detail in Apple’s overview worth knowing before you go looking. Testers using TestFlight version 2.3 or later on iOS, macOS and visionOS can send feedback in two ways: through the TestFlight app, or by taking a screenshot directly inside your beta app. Both end up in the same place. Testers on tvOS or on older iOS versions are different, because they can only send feedback to the email address entered in the Feedback Email field of your test information.

That email field is the first thing to check on an inherited app. It was filled in once, probably by the person who set up the beta, and Apple says it is where feedback goes for anyone who cannot use the in-app route. If it points at the mailbox of a developer who left two years ago, some of your feedback has been going nowhere.

The sidebar also lets you filter. Click Add Filter and you can narrow the view by platform, app version, build group, build, OS version or device. That sounds minor, and it becomes the most useful control in the whole section once you have a few hundred submissions, because a crash that only shows up on one OS version is a different problem from one that hits every build.

What is in a piece of feedback, and what isn’t?

Each piece of feedback opens into a detailed view with the screenshot or crash report, the written comments and information about the tester, the app and the device. For crashes, the zip file you can download contains the crash report and the associated comments. For screenshots, the zip contains the image and the comments. If you have Xcode installed, the detailed view also has an Open in Xcode option for screenshot feedback.

What the feedback does not contain is as important as what it does. Apple’s help page states that if an app becomes unresponsive because of a crash, a crash report won’t be included in the zip file. That is a real gap, because a hang that ends with the tester force-quitting the app is not the same as a crash, and it is the kind of problem a neglected app collects. Feedback from TestFlight can tell you about crashes that produced a report, and it says nothing reliable about the hangs that didn’t.

Apple’s overview says that you can track tester engagement and app performance by viewing build status and metrics, including the number of sessions and crashes. If a build shows a high crash count and almost no feedback, the testers are probably not using the in-app route, and the first fix is a message to them rather than a code change.

How long does TestFlight keep your feedback?

Crash reports are available for download for 120 days, according to Apple’s App Store Connect help, and builds themselves stop being testable after 90 days. Taken together, the two numbers mean that a build uploaded in July is gone for testers by October, and the crash reports that came from it have a similar short life, so evidence from an old beta can vanish while you are still deciding what to do about it.

For screenshots and comments, I couldn’t find a stated retention period in the pages I read, and I’d rather tell you that than guess. Treat the absence as unknown and download anything that matters. The download button sits in the top right of the detailed feedback view, and it saves the feedback as a zip file, which you can drop into your own storage in a minute.

If you’ve just taken over an app, here is the routine I’d run in the first week. Open Crashes, filter to the newest build group, and download everything from the last 120 days while it is still there. Do the same for screenshots, then put the files somewhere the whole team can reach, with the build number in the file name, because six months from now nobody will remember which build a given crash report belonged to and App Store Connect will have stopped showing it.

This is also the point where it pays to look at what the testers are actually running. Apple’s overview says the first build you add to a group goes to App Review when you invite external testers, and that you can test a build for up to 90 days. If your external group is running a build that is nearly out of its 90 days, the people you most want feedback from are about to lose the app, and no crash report will come from a build that no longer opens.

Who can see feedback, and how do testers show up?

Anyone with the Account Holder, Admin, App Manager, Developer or Marketing role can view it, and how a tester appears depends on how they were invited. Apple says that when a tester is invited by an invitation email, their email address appears in the detailed feedback view. When a tester joins through a public link, they appear as anonymous unless they enter their email address while submitting feedback, and then the address is shown only for that one piece of feedback.

That distinction changes how you read the data. A public link is convenient for a large beta, since you can post it anywhere, but it trades away the ability to ask the same person a follow-up question. If you inherited an app whose beta ran on a public link, a lot of your feedback is probably anonymous and you can’t write back to its author. Invited testers are the opposite, since you know exactly who they are, and that is worth the extra effort when you are chasing a crash that only one device model produces.

Apple’s overview also gives the numbers for the two kinds of tester. You can add up to 10,000 external testers, and up to 100 internal testers, who are App Store Connect users with access to your content. Internal testers tend to be your own team, and their feedback arrives faster and with more context, while external testers give you more variety in devices and in how people actually use the app.

Why can’t a tester send feedback from the beta app?

The most common documented cause is group membership. Apple’s help page includes a question about exactly this: a tester is part of a group that has feedback enabled and still can’t submit feedback through the beta app. The answer is that if a tester is part of multiple groups and one of those groups has feedback disabled, the tester will only be able to send feedback by email from the TestFlight app.

That behaviour is easy to create by accident. Someone disables feedback for a group of executives who don’t want to see the screenshot prompt, a developer then adds the same people to a bigger external group, and from that point nobody in the bigger group can use the in-app route. Feedback is switched on or off per tester group, in the group’s settings tab under Tester Feedback, where you click Disable or Enable and then confirm in the dialog.

Apple states that even with feedback disabled in the app, all testers can still send email feedback using the TestFlight app. That keeps a fallback open, but email feedback arrives in a different place and in a different shape, and it is the version of feedback least likely to include a crash report. When a tester tells you they can’t find the feedback option, go through every group they belong to before you suspect the build.

How do you get feedback out of App Store Connect automatically?

Apple gives you two routes, webhooks and the App Store Connect API, and both exist so that feedback doesn’t depend on someone remembering to log in. Apple says that webhooks send automatic notifications to your web server whenever new feedback is submitted through TestFlight, and that you can view crash feedback or screenshot feedback using the App Store Connect API. Apple’s API reference lists a call for beta feedback crash submissions on an app, with filters for build, device model, OS version and tester.

I would not build either one on day one of a takeover. The web interface is enough while you are learning what the app does, and the webhook only becomes worth the setup when feedback arrives often enough that nobody can be trusted to check it by hand. When you do build it, keep it small: receive the notification, record the build and the device, and open a ticket that links back to the feedback in App Store Connect.

Be honest about what the automation can’t do, because the documentation does not claim more than this. A webhook tells your server that feedback exists. It is a notice, and I wouldn’t design a system that assumes it carries the whole crash report, so fetch the details through the API afterward and store them yourself, given the 120-day window on crash downloads.

Does TestFlight feedback replace crash reporting?

No, because it only covers the testers who ran a beta build and chose to send something, while a crash reporting tool covers every production user without being asked. The two answer different questions, because TestFlight feedback tells you what your testers saw before release, with a human comment attached. A crash reporting tool tells you what broke for real customers after release, with counts and trends.

If the inherited app has no crash reporting at all, that is a bigger problem than any hole in the beta feedback, and it usually comes first in a stabilization plan. Our comparison of Crashlytics and Sentry covers the choice, and the mobile app testing checklist covers what to test before a build goes to testers in the first place.

Where TestFlight feedback does something nothing else does is in the comment. A crash report tells you which line failed, and the tester’s note tells you what they were doing, which screen they were on and sometimes what they expected to happen. For a bug that only reproduces in a particular order of taps, that sentence is worth more than the stack trace, and it is the reason I keep the beta alive on a stabilization project instead of testing internally only.

There is a practical rule that follows. Use TestFlight feedback to decide whether a build is ready to ship, and use crash reporting to decide whether the shipped build is healthy. If your release process looks at neither, the first step is to add the cheaper of the two, and that is usually opening the Feedback section you already have.

What should you check first on an app someone else ran?

Check four things in this order: who can see feedback, where email feedback goes, which groups have feedback disabled and what is about to expire. The first takes two minutes in the users and access section, the second is a single field in the test information, the third is a click through each tester group, and the fourth is a look at the build list for anything close to 90 days old. Together they tell you whether the beta program is working or has been quietly broken for a year.

Start with access, because a feedback section nobody can open is the same as no feedback. If the app came to you through an Apple app transfer or an agency hand-off, confirm that your own account has a role that can read it and that the previous owner’s personal address is not the only one on the account. Then fix the Feedback Email field, so anything coming from older devices reaches a mailbox that a person reads.

Next, review the groups by opening each one, go to its settings tab and read the Tester Feedback state, then compare it against the people who sit in several groups at once. Fix any group that was disabled for a reason nobody remembers, or write down the reason if it still holds. After that, check the build list for anything near its 90-day limit and decide whether the testers need a new build before it lapses, remembering that the first build in a group needs a review when you add external testers, which can take time that App Store review timing explains.

Finally, download what is there, since the crash reports will disappear after 120 days whether or not you used them. A one-time export on the first day of a takeover preserves the only record of how the previous releases behaved on real devices. That archive is also the best starting evidence for the conversation about whether the app needs a stabilization project, because it shows crash patterns by device and OS version before anyone has changed a line of code.

If that audit turns up a beta pipeline that is badly broken, or crashes nobody has looked at, app takeover is how we pick up an app with unclear ownership, and mobile app stabilization is the work that comes after, where those crash reports become a prioritized fix list. RapidLabs does both for iOS and Android apps, and the first step is always reading what the app is already telling you, which on a lot of inherited projects is sitting unread in the TestFlight tab.