Symbolication
Symbolication in the Settings area (Apps & data) — route /settings/symbolication.
Symbolication lives in the Settings area of the dashboard, under Apps & data.
At a glance#
| Dashboard route | /settings/symbolication |
| Area | Settings (settings) |
| Group | Apps & data |
| Platforms | Available for every app platform. |
What it does#
Symbolication turns crash reports from release builds back into readable stack traces. This page manages the symbol files that make that possible — iOS dSYMs and Android mapping files — per app version.
When to use it#
Once to set up, then never manually. The correct place for this is your CI pipeline, running on every release build. Uploading by hand works and will be forgotten exactly once — on the release that crashes.
Come here to verify: after a release, confirm the symbols for that version arrived.
Workflow#
Automate the upload in CI
The build that produces the binary is the only thing that has the symbols. Upload from there, in the same job.
Match on version and build number
Symbols are matched to the exact build. A version string that does not match the reporting build leaves the crashes unsymbolicated.
Verify after each release
Check that the version you just shipped has symbols listed. This takes ten seconds and prevents the only truly unrecoverable failure mode here.
Confirm on a real crash
Look at a symbolicated trace in Crashes rather than trusting the upload alone.
Permissions and prerequisites#
Requires an administrative or developer role. You need the symbol artifacts from your build:
iOS — the dSYM bundle for the build. Note that Xcode's own upload to Apple does not put it here.
Android — the mapping file produced by R8 or ProGuard when minification is on.
Limits and edge cases#
Per build, not per version. Two builds of the same version number have different symbols. If your build numbers are not distinct, matching becomes unreliable.
Retroactive symbolication needs the symbols to arrive eventually, and it cannot help a build whose symbols were never produced or were discarded.
Bitcode and store-side recompilation can mean the symbols you have are not the ones for the binary users received. Check what your pipeline actually produces.
Debug builds do not need this and are not a test of whether it works.
Troubleshooting#
Crashes still show addresses. The version and build of the reporting binary does not match any uploaded symbol file. Compare them exactly, including the build number.
Symbols uploaded but only some frames resolve. Frames from system libraries or from a third-party framework need that framework's symbols, which your build does not contain.
A past release has no symbols and crashes are unreadable. If the build artifacts are gone, this is not recoverable. Add the CI step so the next one is fine.
Where the data comes from#
From the SDK
Served by
symbolication— internal module, no public endpointsSymbols