How to send TestFlight feedback and find it in App Store Connect

To send TestFlight feedback on an iPhone or iPad, open TestFlight, select the beta app and tap Send Beta Feedback. Developers review submissions in the app’s TestFlight area in App Store Connect. The useful part is what accompanies the screenshot: the starting state, the action that failed and the result the tester expected.

This guide covers the reporting handoff between an iOS tester and the person investigating the issue. For planning the whole test round, start with the mobile beta testing checklist.

How do you send feedback from TestFlight on an iPhone or iPad?

Use the TestFlight app when you want a consistent starting point:

1. Select the beta app in TestFlight.
2. Choose Send Beta Feedback and decide whether to include a screenshot.
3. Write the observation and the steps that led to it, then submit the feedback.

You can also start from a screenshot taken inside the beta app: open its preview and look for Share Beta Feedback. If you have already dismissed the screenshot preview, use the TestFlight route above. Apple documents both paths in its guide to giving TestFlight feedback.

A screenshot shows the visible result. Use the comment to explain the action or state that the image cannot show, such as which account was signed in or whether the app had just returned from the background.

What should a tester write alongside the screenshot?

Write one problem per submission. “The total is wrong” tells an engineer where to look, but leaves the investigation dependent on another conversation. A useful comment makes the mismatch explicit.

Here is an illustrative report for a fictional expense app:

Summary: Expense total keeps the old amount after editing a receipt

Starting state: Signed in to the supplied test account, with one draft expense.
Steps:
1. Open the draft expense.
2. Change its amount from 12.00 to 18.00 and save.
3. Return to the expenses list.

Expected: The list shows 18.00 for the edited expense.
Actual: The list still shows 12.00. Reopening the expense shows 18.00.
Frequency: Reproduced twice from the same starting state.
Impact: I cannot trust the list total while reviewing expenses.

If you saw the problem once, say so. If you tried again and it worked, record the difference rather than presenting the failure as deterministic. Keep passwords, access tokens and real customer records out of both the comment and the screenshot.

For a longer report, the beta issue template helps organise the build, environment, steps and evidence before you submit it. Agree which fields the team needs so testers spend their time explaining the failure rather than filling in a form.

Where do developers find TestFlight screenshot and crash feedback?

In App Store Connect, open the app and select TestFlight. Under Feedback, choose Screenshots or Crashes. Open a submission to inspect it, narrow the list with filters, or download the feedback as a ZIP. See Apple’s instructions for viewing tester feedback.

The detailed feedback view includes the installed app version and build, device model, OS version and connection information. Use that context to match the observation to the build you are investigating. A tester’s description still matters: device metadata does not explain how they reached the failing state.

Before asking the tester to repeat the report, compare the submission with the release you are currently testing. An issue on an older build may need a retest on the candidate build; a new regression needs a different investigation from a previously known problem.

Why might TestFlight feedback be missing or unavailable?

Check the app and filters first. For a tester who cannot submit in-app feedback, check their group settings: Apple says membership in any group with feedback disabled prevents that route, even if another group enables it. Email feedback remains available through TestFlight. This behaviour is documented under disabling feedback in Apple’s feedback guide.

Use a small diagnostic handoff rather than asking for the entire report again:

• Ask which app and build the tester used.
• Confirm which reporting route they chose and whether they completed submission.
• Check whether the expected item is screenshot feedback or crash feedback.
• For a time-sensitive blocker, use the team’s agreed escalation channel while someone checks the normal reporting route.

Keep the diagnostic conversation attached to the issue once it is found. Otherwise the explanation for a missing report becomes another piece of context lost in chat.

How do you turn TestFlight feedback into an owned engineering issue?

Assign someone to review incoming feedback during the beta. For each actionable observation, decide whether it is a new defect, a duplicate, a question or an expected behaviour that needs better explanation. Create or update the engineering issue with:

Information	What the next engineer needs
Build and environment	The affected version, build, device and relevant account state
Reproduction	The starting state and the smallest known sequence of actions
Expected and actual result	The precise mismatch, with the original evidence attached or referenced
Release impact	Which user task fails and whether a workaround exists
Ownership	Who investigates, what evidence is missing and when to review it again
Verification	The build and scenario that will demonstrate the fix

If the observation is a duplicate, preserve any new device or build information before linking it to the existing issue. A second report can reveal that a defect affects a wider set of conditions.

Apple also provides API access to beta screenshot feedback and webhook notifications for new submissions. Teams can use those facilities to build an automated handoff; that still needs an integration and a clear owner for the resulting work. The mobile beta feedback workflow covers triage and closing the loop with testers across a growing cohort.

When does a separate in-app reporting route help?

Apple’s native feedback route may cover your iOS beta’s needs. A team testing both iOS and Android may also want a consistent report form and delivery into the issue tracker it already uses.

With BugScreen’s iOS SDK, a submitted report can carry screenshots, app version and build, device details and recent application logs. The companion app offers a route for screenshots and tester-entered context when you cannot modify the build. Because it runs outside the tested app, it cannot read that app’s logs or build metadata.

BugScreen collects these reports through its own reporting flow; it does not import the TestFlight feedback described above. Give testers one default path for actionable issues, with clear instructions for when to use another route. The TestFlight feedback solution explains where BugScreen fits, and you can create a workspace to try the reporting flow with your team.