Crashes & Diagnostics
Crashes are the #1 cause of user churn and review rejection. App Store Connect’s “Crashes” and “Diagnostics” reports help you spot stability problems quickly and locate root causes.
What’s in a Crash Report
Go to App Store Connect → select the app → the Crashes page to view:
| Info | Use |
|---|---|
| Crash stack | The call chain at the crash; locates exact code |
| Crash type | SIGABRT, EXC_BAD_ACCESS, SIGSEGV, memory warnings, etc. |
| Affected version | Regression vs historical issue |
| Affected device/OS | Whether concentrated on specific devices or OS versions |
| Crash count & users | Impact assessment and priority |
| Sessions/crash rate | Overall stability level |
Reading a Crash Stack
- Find your own code: skip system framework frames; focus on the last few frames in
YourApp. - Note the crash type: memory-type (EXC_BAD_ACCESS) often relates to pointers/lifecycle; SIGABRT is often an assertion,
fatalError, or main-thread issue. - Correlate with version: if only in one version, compare that version’s changes (git log) to locate quickly.
- Symbolication: after uploading dSYM, stacks become readable function names and line numbers — always configure dSYM upload in CI.
Crash reports may show only addresses without function names — that’s “unsymbolicated”. Configure dSYM in App Store Connect, or import via Xcode Organizer, to get readable stacks.
Diagnostics
Beyond crashes, the diagnostics page also provides:
- Hang: main thread blocked for a long time, hurting UX.
- Power & resources: high energy usage problems.
- Disk writes: abnormally high disk I/O.
These aren’t fatal but significantly affect reputation and retention — include them in the stability dashboard.
Stability Loop
- Discover: spot abnormal rises via crash-rate trends and version comparison.
- Locate: read the stack + correlate version changes + reproduce.
- Fix: fix and add regression coverage; verify via TestFlight first.
- Verify: after release, confirm that version’s crash rate comes back down.
Set quantitative stability goals, e.g. “crash rate below 0.5% per version” and “P0 crash response within 24 hours”. With measurable thresholds, stability stops being a slogan.
Self-Check List
- CI / Xcode configured with dSYM upload and symbolication
- Crash reports filtered by version / device / OS
- High-frequency crashes located and scheduled for fix
- No P0 crashes confirmed before submission
- Hang / energy / disk diagnostics reviewed
FAQ
- Can’t see crash data? Check dSYM upload, whether the app is distributed via TestFlight/App Store, and statistics delay.
- Crash only on real devices, not the simulator? Many crashes relate to real memory, background, and push — you must test on real devices.
- Crash caused by a third-party SDK? Upgrade the SDK, check known issues; confirm in the stack and work around or contact the SDK vendor.
- High crash rate but few users? Rank by “crash users × frequency” rather than just count.