Find iOS crash logs and symbolicate them

Overview

If a crash happens away from your debugger, the job becomes two separate problems: getting the report and then turning the raw addresses back into code locations.

That is the split this article handles well. First it shows where crash logs can be found, depending on whether the phone is connected to Xcode or only available on its own. Then it walks through symbolication, which is what turns anonymous memory addresses into useful symbols and source-level clues.

The article frames three practical retrieval paths:

debug while the device is connected to Xcode, inspect a symbolicated crash in Xcode's device logs, or pull an unsymbolicated crash straight from the phone and decode it later with the matching dSYM.

Why It Matters A symbolicated crash log can tell you the exact function and often the line region that failed. That is what makes reports from App Review, testers, or field devices actually actionable.

Xcode Retrieval

The easiest path is still the connected-device flow inside Xcode.

If you can reproduce the problem with the phone plugged into your Mac, Xcode can surface the device logs directly and usually show them in a symbolicated form right away.

The article's path is:

open Window > Devices and Simulators, choose the physical device in the left sidebar, then click View Device Logs.

Xcode Window menu showing Devices and Simulators — Start from Xcode's device-management window.

Connected device selected in the Xcode device window — Select the physical device first, then move into its logs.

Device crash logs shown in Xcode — Xcode can list the device's crashes and make them searchable by app name.

This is the least painful path because Xcode is already holding the relevant build metadata and symbol files for recent local builds.

On-Device Retrieval

If Xcode is not involved, the phone itself can still provide the raw crash report through Analytics Data.

That route is useful when the crash happened in the field or when someone else is sending you the report. The log you get there is not the friendly final answer yet, but it is enough to decode later.

The path in the article is:

Settings → Privacy → Analytics & Improvements → Analytics Data.

Settings app with Privacy selected — Start from the device's privacy settings.

Analytics and Improvements settings on iPhone — Open the analytics section where diagnostic reports are stored.

Analytics Data list in iPhone settings — `Analytics Data` is the log list view.

Search results for a specific app's crash logs in Analytics Data — Search by your app name, then open a report and send it to the Mac with AirDrop or another share path.

Xcode Symbolication

If the matching archive is still available, Xcode is often the shortest route to a readable crash.

The article distinguishes between already-symbolicated logs in Xcode and raw reports coming from somewhere else. For the latter case, the next problem is making sure you have the right archive and dSYM for the exact build that crashed.

If you archived the build, you can start from the Organizer or from the archive package itself and work outward from there.

dSYM Lookup

Everything depends on matching the crash report to the correct dSYM.

The article first shows the manual archive route. In Finder, open the archive package contents, then look for the bundled dSYM file.

Showing package contents for an Xcode archive — Archives can be inspected directly as packages.

dSYM item inside an Xcode archive — The archive contains the symbol files you need for later symbolication.

dSYM file visible in the archive contents folder — Once you have the dSYM on disk, the command-line tools can use it.

The second route is to match by UUID. The article points out that the relevant UUID can be found in the crash report's Binary Images section.

UUID shown in the Binary Images section of a crash report — The UUID in the crash report is what lets you search the Mac for the exact matching dSYM.

mdfind "com_apple_xcode_dsym_uuids == <UUID>"

That search helps when you have many archives or no longer remember where the build artifacts were stored.

symbolicatecrash

The classic command-line path uses `symbolicatecrash` with the right dSYM and the raw crash report.

This article first exports the Xcode developer directory, then runs the bundled symbolication tool directly from Xcode's framework path.

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -d <path_to_dsym> -o <output file> <path_to_crash_report>

In plain terms:

<path_to_dsym> is the matching symbol file, <output file> is where the decoded report should be written, and <path_to_crash_report> is the original raw crash log.

atos

`atos` is the more surgical option when you want to decode one stack address manually.

This route uses several values taken from the crash report itself: the binary architecture, the load address, and the stack address.

atos -arch <binary architecture> -o <dSYM file path> -l <Load address> <Stack Address>

The article points to the exact places those inputs come from inside the report:

Binary architecture location in a crash report — The architecture value comes from the first line of the `Binary Images` block.

Load address location in a crash report — The same block also gives you the image load address.

Stack address location in a crash report — The stack address is the first address on the relevant crashing frame line.

The article's sample command looks like this:

atos -arch arm64 -o <dSYM file path> -l 0x10237c000 0x000000010243bd64

If the dSYM and addresses line up, the output should resolve the anonymous address back to the symbol that actually crashed.

Newer Tools

The post was later updated with a short note that iOS 15 and later also introduced newer crash-analysis tooling.

That note is worth keeping in mind if you are reading this in a newer environment: the workflow here is still useful, but it is also a picture of the older archive-and-dSYM-heavy path that many teams still rely on for manual investigation.

Wrap Up

The essential habit is to treat crash handling as a reproducible pipeline: collect the right report, match the right symbols, then decode with the simplest tool that fits the situation.

Xcode is easiest when you still have the device and archive close at hand. The device's Analytics Data view helps when the report must be pulled after the fact. symbolicatecrash handles full reports, and atos is useful for targeted manual lookups.