How Crashlytics works in iOS? An Overview of dSYM 🤔
The First priority of any Developer is to provide Users the best experience with stable and bug free end-product by using the system resources efficiently. And good news is that the operating system helps us meet these expectations by collecting different log types we can use to diagnose issues in our app.
From Apple’s Documentation: https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information
When Xcode compiles our source code into machine code, it generates a list of symbols in our app — class names, global variables, and method and function names. These symbols correspond to the file and line numbers where they’re defined; this association creates a debug symbol, so you can use the debugger in Xcode, or refer to line numbers reported by a crash report. Debug builds of an app place the debug symbols inside the compiled binary file by default, while release builds of an app place the debug symbols in a companion Debug Symbol file (
dSYM) to reduce the size of the distributed app.
đź’ˇ Let us try to understand the above complex statement in a detailed and simple manner.
When an app crashes, the operating system collects diagnostic information about what the app was doing at the time of crash. One of the most important parts of the crash report are the thread backtraces, which are reported as hexadecimal addresses.
An example of an unsymbolicated crash report:
What is SYMBOLICATION?
Now to understand the root cause of our App crashes, first we need to translate Thread backtraces into human readable language (i.e. function names and line number in our source code that caused the crash). This process is called symbolication.
More details on symbolication can be found here:
Role of dSYM (Debug SYMbol)
Without dSYM the crash report will just show memory addresses of objects and methods. We won’t be able to read any crash reports without first re-symbolicating Binary files.
dSYM files store the debug symbols for our app. It contains mapping information to decode a stack-trace into readable format.
The purpose of dSYM is to replace symbols in the crash logs with the specific methods names so it will be readable and helpful for debugging the crash.
Key points regarding dSYM
The dSYM file is created when the application source code is compiled with the Debugging Information Format set to DWARF with dSYM file
dSYM files change every time we compile our App having code changes.
The dSYM file contains a UUID that links it to a specific Xcode build. The consequence is that symbolication only works if the UUID of the binary that caused a crash matches the UUID of the dSYM that is used for symbolication.
The benefit of using the dSYM is that we don’t need to ship our App with its symbols which makes it difficult to reverse engineer our app. This also reduces our App binary size.
How to enable dSYM?
- In Xcode, select your project in the Project Navigator.
- In the target list, select the target that builds your application.
- Select the Build Settings tab.
- In the Build Options section, make sure that the Debugging Information Format is set to
DWARF with dSYM File.
Note: It is recommended to Set Debug to “DWARF” instead of “DWARF with dSYM File” to reduce the compile time.
