Crash logs
iOS writes a crash report to the device as soon as a process terminates. This module exports the report from the device and formats it for reading.
Get a report
Section titled “Get a report”- Connect the device where the crash happened. Reports are stored only on that device.
- Open Crash logs.
- Find the entry by app name and time.
- Export it, or read it in KeyMob.
Reports accumulate over time. You can delete reports you no longer need from this module.
Symbolication
Section titled “Symbolication”A raw report contains memory addresses. Symbolication converts them into function names and line numbers.
The symbols must match the exact binary that crashed: same version, same build. Keep the dSYM for every build you release. Without it, frames from your own code stay as hexadecimal addresses in any tool. System frames are symbolicated with the OS symbols for that iOS version.
Read the report
Section titled “Read the report”Read the report in this order.
1. Exception type. This is the most informative line.
| Type | Usually means |
|---|---|
EXC_BAD_ACCESS (SIGSEGV) |
Access to invalid memory, such as a released object or a bad pointer |
EXC_CRASH (SIGABRT) |
An uncaught exception, a failed assertion, or a deliberate abort() |
EXC_BREAKPOINT (SIGTRAP) |
A Swift runtime trap, such as force-unwrapping nil, an index out of range or a failed forced cast |
EXC_RESOURCE |
A resource limit was exceeded, usually memory or sustained CPU |
0x8badf00d |
Watchdog termination. The app took too long to launch or respond, and iOS terminated it |
0xdead10cc |
The app held a file lock or shared resource while suspended |
2. Termination description. When present, it names the assertion or exception directly. Read it before the backtrace.
3. The crashed thread. It is labeled in the report. This is the stack to read.
4. Your frames. Look down the crashed thread for frames from your own binary. System frames above them usually show only how execution reached your code. Start with the topmost frame from your code.
Reports that are not crashes
Section titled “Reports that are not crashes”Two kinds of entries look like crashes but are not:
- Jetsam (memory) reports. iOS terminated the process for using too much memory. The top of the stack does not show the bug. The cause is the memory growth before the termination. Confirm it with a memory trace in Performance.
- Watchdog terminations. The main thread was blocked. The backtrace shows where it was blocked, not what caused it. Look for synchronous I/O or a lock.
If you cannot reproduce the crash
Section titled “If you cannot reproduce the crash”- Get the report from the device where the crash happened. A similar device is not the same.
- Read the live log around the crash time. The app’s last messages are often more useful than the stack.
- Check usage history for other activity at that time.
- Check device information: iOS version, free storage and battery health. A crash that happens “only on that phone” often happens only when its storage is full.