Why your TestFlight feedback emails go missing (and what to do about it)

If you ship via TestFlight, this has happened to you. A tester writes up the bug — describes the repro, takes a screenshot, hits Send — and then… nothing. Three weeks later you find out about it accidentally, when the same tester asks, “did you ever look at that crash I sent?”

TestFlight feedback is some of the best signal you’ll ever get on an iOS build. Real users, real devices, real bugs, often with screenshots attached. The problem isn’t the feedback. It’s how Apple delivers it.

Apple delivers TestFlight feedback by email

By default, when a tester submits feedback, App Store Connect sends an email to whoever’s listed as the contact for tester feedback on that app — usually a single person, usually whoever’s name happened to be on the Apple ID when the app was first set up. That’s it. One email. To one inbox. Per piece of feedback.

If that inbox is a personal account, there’s a single human between every TestFlight comment and the rest of the team:

• They have to be at their inbox.
• The email has to land in their primary tab, not Promotions, not Bulk.
• They have to be willing to forward it on, or summarise it for the team in Slack, or copy-paste it into the bug tracker.
• They have to do this for every single submission, every day, forever.

Even the most disciplined indie dev fails at this. As soon as you ship more than one TestFlight build a week, feedback starts piling up unread.

The specific reasons feedback emails go missing

In rough order of how often I’ve seen each one bite:

1. Sent to the wrong inbox. The Apple ID on the developer account is often someone’s personal address, or a long-departed teammate’s, or a shared apple@yourdomain.com that nobody actually monitors.
2. Gmail/Outlook filtering. Apple’s TestFlight feedback emails come from no_reply@email.apple.com and contain a lot of boilerplate. Gmail in particular has been increasingly aggressive about classifying them as low-priority bulk mail, especially for accounts that haven’t engaged with them before.
3. Volume blindness. Once you get more than a few a week, your brain starts treating “you have a new TestFlight feedback email” the same way it treats “your subscription is expiring soon” — a thing to deal with later. Then never.
4. Out of office. Most TestFlight feedback comes in over weekends and evenings — exactly the times nobody’s watching that inbox.
5. The “Send to” dropdown is one-deep. App Store Connect doesn’t let you fan out feedback to multiple addresses, set up an aliased team list, or route different apps to different recipients. It’s one email, one human, take it or leave it.

The workaround everyone tries first is logging into App Store Connect and refreshing the feedback tab manually. Which works, until it doesn’t. There’s no notification when a new piece of feedback arrives in the UI either — you have to go look. And in a small team, “go look at the App Store Connect feedback tab” sits behind “answer this Slack ping” and “respond to that customer email” every single time.

The actual fix

Apple ships every TestFlight feedback submission as a webhook event called betaFeedbackCreated, via App Store Connect Webhooks. The event arrives within seconds of submission and carries the tester’s comment, the build it was submitted against, and device info (model, OS version, locale).

You can wire that up to a Slack channel. The whole team sees every piece of feedback in real time, in the place the team already lives. No email forwarding, no manual refreshing, no single point of failure.

That’s the entire fix.

In practice it looks like this:

1. Create a dedicated #testflight-feedback channel in Slack.
2. Point App Store Connect’s webhook URL at Juice Machine.
3. Add a Slack destination pointed at that channel.
4. Filter the destination to just the betaFeedbackCreated event (so the channel stays focused — App Store Connect webhooks include a lot of other event types you might not want here).
5. Done. Next tester comment arrives in Slack within a few seconds of being sent.

Each Slack message includes the tester’s comment, the build version, the device model, and a link straight to the feedback in App Store Connect for the screenshot and full context. Crash submissions come through the same way, with a link to the crash details in App Store Connect.

If you want the longer version of the setup, the TestFlight feedback in Slack use-case page walks through it step by step, and the App Store Connect setup guide covers configuring the webhook URL itself.

A few things worth knowing

The betaFeedbackCreated event fires for both comments and crash submissions. If you want them separated — say, comments to #testflight-feedback and crashes to PagerDuty — that’s a one-line filter difference per destination.

Apple still sends the email too. Adding the webhook doesn’t disable email notifications, so if there’s an inbox already watching them, that keeps working as well. Belt and braces.

Testers see your team name in App Store Connect. When a tester submits feedback, they see whichever name your developer account is registered under. Worth a quick check that it says something professional rather than “John’s MacBook Pro”.

The webhook covers every TestFlight build going forward. You don’t need to redeploy or update anything in your app. The hook is on the App Store Connect side; your binary doesn’t change.

TL;DR

• TestFlight feedback by default emails one person, who is often distracted, on holiday, or has Gmail filtering it.
• Apple’s betaFeedbackCreated webhook ships the same data, in real time, with the same context (build, device, comment, screenshot link).
• Pointing that webhook at a Slack channel means the whole team sees feedback the moment it’s submitted, with zero ongoing work.
• Juice Machine does this in about three clicks via the TestFlight-feedback-in-Slack use case.