Guide · Updated July 2026

TestFlight Feedback, Explained

TestFlight is how iOS betas reach people — up to 100 internal testers from your own team, up to 10,000 external ones. What many developers only half-know is that it ships with a feedback system you never have to build: testers can send marked-up screenshots and crash reports straight from your app, and it all lands in App Store Connect. No SDK, no code, nothing to integrate.

This guide walks the whole path: what testers actually see, where the feedback goes, the limits Apple doesn't print on the label, and the part TestFlight leaves entirely to you — turning a tester's screenshot into a shipped fix.

How testers send feedback

There are three routes, and none of them require anything in your code.

The screenshot flow. This is the main one:

1. The tester takes a normal screenshot inside your beta app.
2. They tap the screenshot thumbnail, then the share icon.
3. iOS offers Share Beta Feedback — an option that only appears in apps installed through TestFlight.
4. They can draw on the screenshot to mark up what's wrong, type a comment, choose whether to attach the image, and send it.

That's the entire tester-side experience. Note there is no shake gesture — shake-to-report belongs to third-party SDKs like Shake and Instabug, not to TestFlight. In TestFlight, the screenshot is the trigger.

The crash dialog. If your beta app crashes, TestFlight shows the tester a dialog offering to send the crash report, with an optional comment about what they were doing. That comment is regularly worth more than the stack trace under it.

The TestFlight app itself. Each app's page inside the TestFlight app has a Send Beta Feedback option for written feedback that isn't attached to a screenshot or a crash.

Testers agree to share feedback when they join your beta; everything after that is manual on their part. That detail matters more than it sounds — we'll come back to it.

Where feedback lands in App Store Connect

Open your app in App Store Connect, go to the TestFlight tab, and find the Feedback section in the sidebar. It has two views: Screenshots and Crashes.

Each screenshot entry shows the image with the tester's markup, their comment, and context you'd otherwise have to ask for: app version and build number, device model, OS version, battery level, connection type, and free disk space. You can filter by platform, app version, build, OS version, or device, and download the screenshots for anything you want to keep.

Since WWDC 2025 this is also reachable programmatically: the App Store Connect API can list beta feedback screenshots and crash submissions and download their attachments, and webhooks can notify your server the moment new feedback arrives (checked July 2026). Before that, pulling feedback out of App Store Connect was a years-old fastlane feature request; now it's a supported endpoint.

What TestFlight feedback captures — and what it doesn't

That last row is the one that surprises people, so let's spell out the limits properly.

The real limits

It only exists in beta builds. The moment your app ships, the Share Beta Feedback flow disappears for real users. Production users get no built-in way to send you a screenshot — which is a problem, because users don't report bugs, they leave.

Builds expire after 90 days. Every TestFlight build is available for up to 90 days from upload, then it expires — testers can't install or even open it, and there's no extension. An abandoned beta goes dark on its own schedule, taking its feedback stream with it. Keep shipping builds or the channel closes (checked July 2026).

It's one-way. You can see which tester sent what, but there's no reply thread, no "can you tell me more", no way to tell them it's fixed. TestFlight hands you a report, not a conversation.

It depends entirely on tester initiative. The flow is discoverable but optional. Most testers hit a bug, sigh, and keep scrolling. The feedback you receive is a sample of what they hit, biased toward your most patient users.

It stops at the report. This is the structural one. A screenshot in App Store Connect is evidence, not progress. Nothing connects it to your codebase, your agent, or a fix. Everything downstream of the Feedback tab is your problem — so let's do that part properly.

From tester screenshot to shipped fix

1. Triage in the Feedback tab. Group screenshots by build and screen. Five screenshots of the same broken state is one bug with five witnesses.
2. Reproduce it once yourself. The metadata helps — same OS version, similar device class, low battery, cellular instead of Wi-Fi.
3. Hand your agent the actual screenshot. Download the image and give it to Claude Code, Codex, or Cursor along with the build number and the tester's comment. A marked-up screenshot beats any prose description you could write about it — that's the core of the vibe debugging loop.
4. Make the agent prove the fix. Before/after, not "done". The React Native debugging guide covers verifying on-device behavior.
5. Ship it back to testers. A new TestFlight build — or, if you're on Expo and the fix is JavaScript-only, an EAS Update that reaches existing builds in minutes. The Expo testing guide covers that path.

Here's the honest gap: TestFlight's loop is built for other people testing your app, and it ends at a screenshot in a dashboard. When you're the builder — dogfooding your own app, hitting bugs daily — Vibejar is the same gesture, wired to the other end: capture the bug in your app, circle what's wrong, and it lands directly in your coding agent, which ships the fix and sends back before/after proof. No dashboard in the middle.

For the wider landscape of device clouds, capture SDKs, and automation, see the mobile app testing tools roundup.

Frequently asked questions