TestFlight Feedback: Where It Lands and How to Act on It

A beta is useful when testers tell you what went wrong, and when you do something with what they tell you. TestFlight has feedback built in: testers can send a marked-up screenshot or a comment after a crash, and it all lands in App Store Connect. This guide covers how that works, where to find it, and a routine that keeps it from piling up. Apple's details below are from its own pages as of 22 January 2026.

Shipping on Android too? The Google Play version of this guide is Google Play Testing Feedback: Where Tester Reports Land.

The short version

• Testers send feedback from inside your beta by taking a screenshot, or from the TestFlight app. After a crash they can add a comment to the report.
• It appears in App Store Connect under TestFlight, split into Screenshots and Crashes, with filters by build, OS version and device.
• App Store Connect webhooks can call your server when new TestFlight feedback arrives.
• TestFlight feedback is about a build. Feature ideas need a home that outlives the build.

How testers send feedback

As of 22 January 2026, Apple's TestFlight overview says testers running TestFlight 2.3 or later on iOS, macOS and visionOS can submit feedback either through the TestFlight app or by taking a screenshot inside your beta. Apple's TestFlight page adds that they can mark up the screenshot before sending it. If your beta crashes, you get the crash report and the tester can add context to it.

Testers on tvOS, or on earlier versions of iOS, send feedback to the feedback email address you entered in the test information. Check that this address is one somebody reads.

Where it lands in App Store Connect

Open your app, choose the TestFlight tab, and look under Feedback in the sidebar. As of 22 January 2026, Apple's help page View tester feedback describes two lists:

• Screenshots: each tester's screenshot and written comment.
• Crashes: submission times and crash details, with any comment the tester wrote.

Both lists can be filtered by platform, app version, build group, build, OS version and device. Opening an item shows the full comment with details of the tester, the app and the device. From there you can open screenshot feedback in Xcode, or download the item as a .zip file with the screenshot or crash report and the comments. Apple notes that when an app becomes unresponsive, the crash report is not included in the .zip.

Who sent it

A tester invited by email shows with their email address. A tester who joined through a public link appears as anonymous, unless they type an email address when sending feedback, in which case it shows on that one item. If you need to follow up with link testers, ask them in your What to Test notes to include an address.

Switching it off for a group

You can disable in-app feedback for a tester group in the group's settings, under Tester Feedback. Testers can still send email feedback from the TestFlight app. Apple's help page notes a catch: if a tester belongs to several groups and one of them has feedback disabled, that tester is limited to email feedback.

Getting told when feedback arrives

Checking App Store Connect by hand works for a small beta. For anything bigger, use webhooks. As of 22 January 2026, Apple's help page Manage webhooks lists new TestFlight feedback as one of the events App Store Connect can send to your web server, alongside build and app version status changes. A webhook applies to one app, you can create up to ten per app, and each has a secret your server uses to check the delivery came from App Store Connect. You can send a test delivery, and see recent deliveries with their status.

A small endpoint that forwards each delivery to your team's chat is often all you need. The point is that nobody has to remember to look.

A routine for working through it

Feedback that nobody reads is worse than no feedback, because testers notice. A routine for a small team:

1. Look daily during an active beta. Ten minutes, same time each day.
2. Sort each item into one of four piles: crash, bug, confusion, idea. Confusion is a design problem, not a tester problem.
3. Reproduce crashes and bugs on the build named in the report. The filters make it easy to see whether one build or one OS version is to blame.
4. Reply to the tester. If you invited them by email, a short note saying it is fixed in the next build keeps them testing.
5. Move ideas somewhere they will survive. More on this below.

What TestFlight feedback is not built for

TestFlight feedback comes to you one report at a time, tied to a build. That is right for bugs, but it is a poor fit for feature ideas:

• Thirty testers can ask for the same thing in thirty separate screenshots, and nothing adds them up for you.
• Testers cannot see that someone already asked, so they cannot simply agree.
• Your App Store users, who are most of your users, never see TestFlight at all.

So treat TestFlight as the bug channel and give feature requests their own place, ideally inside the app, where every user can find it. Asking in-app also keeps requests out of your App Store reviews, which is a better outcome for everyone. There is more on that in our guides to asking for ratings with SKStoreReviewController and replying to App Store reviews.

How FeedbackKit fits in

FeedbackKit gives feature requests that home. Users post requests, vote and comment inside your app, and one idea gathers votes instead of turning up thirty times. A new request starts with its submitter's vote.

The part this guide is about is the loop back to people. When you move a request to TestFlight, the people who wanted it can see in the app that it is in beta, which is a natural moment to invite them into your TestFlight group. When it reaches Completed:

• The person who submitted it is emailed on every plan, when the new status is in the project's list. Choosing that list needs Pro.
• Voters who opted in to updates are emailed too, on Team.
• On Pro and up, Slack gets a post about the status change. Your team already gets push notifications in the FeedbackKit app for new requests and comments, on every plan.

The details of those emails are in our guide to closing the loop, and plans are on the pricing page. Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

TestFlight tells you what broke. Your users can tell you what to build, if you give them a place to say it and tell them when it lands. Start free, and see our TestFlight beta testing guide for setting up the beta itself.