Feedback & Crashes
Testing is not “send out the package and you’re done” — its real value is getting feedback back and closing the fix loop. This chapter covers how to collect, interpret, and act on test feedback and crashes.
How Testers Give Feedback
Testers can give feedback in two ways from the installed build:
- In-app feedback in TestFlight: open the app’s detail page in TestFlight, tap the feedback entry (or shake the device), describe the issue, and attach screenshots.
- Automatic crash reporting: when the app crashes, crash info uploads to App Store Connect’s crash reports automatically.
Tell testers “where to give feedback” in your test instructions. Many users don’t know TestFlight has a built-in feedback entry and end up leaving App Store reviews instead, causing negative ratings.
Viewing Feedback in App Store Connect
- Feedback list: TestFlight → the app → the “Feedback” area — see text feedback, screenshots, and device info from testers.
- Crash reports: go to the “Crashes” page — filter by version, device, and OS to view crash stacks.
How to Read Crash Reports
Crash reports are the most important material for locating stability problems. Pay attention to:
| Info | Description |
|---|---|
| Crash stack | The call chain where the crash happened, locating the exact code |
| Crash type | e.g. SIGABRT / EXC_BAD_ACCESS / memory issues |
| Affected version | Which version concentrates the crashes — regression or legacy |
| Device/OS | Whether it’s specific to certain devices or OS versions |
| Count & users | Impact assessment to set fix priority |
Priority mnemonic: “high-frequency × high-impact” first. A crash affecting many users should be fixed first even if the stack looks simple; low-frequency crashes on old OS can wait.
The Fix Loop
A standard testing feedback loop:
- Collect: unify feedback and crash reports.
- Triage: classify by module (login, payment, home…) and severity (crash / feature blocked / experience).
- Locate: find root cause via stack, logs, and reproduction steps.
- Fix: fix and add regression coverage.
- Verify: upload a new build; have relevant testers re-test.
- Record: document in release notes / What’s New.
Stability Gate Before Submission
Before full review submission, judge “stable enough” with these criteria:
- No known P0 crashes (affecting core paths).
- Core flows (signup, login, payment, main features) verified on real devices.
- Main devices and OS versions smoke-tested.
- Known issues have workarounds or are disclosed to reviewers.
- High-frequency issues in crash reports located and fixed.
FAQ
- Can’t see crash reports? Ensure the app uploads dSYM for symbolication in Xcode and that crash reporting is enabled in App Store Connect; simulator crashes don’t upload.
- Tester feedback is scattered — how to manage it? Use a simple feedback template (device / OS / reproduction steps / expected behavior) to reduce noise.
- Are internal and external feedback separate? All tester feedback aggregates in one place; filter by group or build.
A good testing process is “surfacing problems in the test phase, before release”. TestFlight’s feedback and crash capabilities turn production incidents into a pre-submission fix list.