Search for a command to run...
Gain high-level understanding about iOS Symbolication and Crash Reporting Providers
I am a Software Engineer working on open source and enterprise mobile SDKs for iOS and MacOS developers written in Swift. From 🇩🇪 and happily living in 🇺🇸
No comments yet. Be the first to comment.
WWDC26 kicked off on June 8, 2026. The information in this article reflects the information published by Apple on that date. There are 14 new frameworks. Name Description AccessoryAccess Manage
WWDC25 kicked off on June 9, 2025. The information in this article reflects the information published by Apple on that date. New Frameworks NameDescription AlarmKitSchedule prominent alarms and countdowns to help people manage their time. AVR...
WWDC25 is almost here, and I couldn’t be more excited! Whether you're attending the official events, community meetups, or just soaking in the energy around Cupertino, there’s no better time to connect, share ideas, and celebrate everything we love a...
In this blog post, I’ll share an observation and advice regarding the caching behavior of network responses by Apple’s APIs. If you are unfamiliar with caching of network responses then I recommend Apple’s article Accessing cached data that introduce...
WWDC24 kicked off on June 10, 2024. The information in this article reflects the information published by Apple on that date. New Frameworks NameDescription AccessorySetupKitUse AccessorySetupKit to discover accessories with Bluetooth or Wi-Fi...
Do you use a crash reporting solution to gain insights into your iOS application? Have you ever wondered why crash reports might contain gibberish and why crash reporting solutions ask you to upload so-called dSYM files?
Then this short blog post is for you :)
When Xcode compiles your source code into machine code, it generates a list of symbols in your app, i.e. class names, global variables, and method and function names. These symbols correspond to the file and line numbers where they're defined.
Debug builds of an app place the debug symbols inside the compiled binary file by default. Release builds of an app place the debug symbols in a companion Debug Symbol file (.dSYM) to reduce the size of the distributed app.
When a crash occurs on the device, a crash report contains stack traces for all running threads of your app at the time a crash occurred. But those stack traces only include memory addresses.
Your crash reporting solution needs those dSYM files to make them human-readable. This process of "translation" is called symbolication.
A fully symbolicated crash report has function names on every frame of the backtrace, instead of hexadecimal memory addresses. Once a crash report was symbolicated then the crash reporting solution can group them smartly together.
Hence you need to upload dSYM files.
Remember that each binary file in an app has its dSYM file, so you might need to upload multiple files for a single app.
For example, you have an iOS application that includes a watch extension, and your app uses a framework. Then you have to upload three files:
Let me quickly talk about crash reporting solution providers.
All major providers share the basic capabilities of
I do not want to recommend any specific provider. There are plenty, here are just a few names in no particular order:
I encourage you compare them as the offering of advanced capabilities varies. Examples are listed below.
Go with the solution provider of your choice, and I hope you understand why uploading dSYM files are necessary.