I am trying to map my understanding of "DWARF" vs "DWARF with dSYM file" debugging info formats to what I see in the crash information for different iOS build configurations.
I was trying to fix a problem, where crashes on the build with debug configuration were not symbolicated by default. These were my build settings before the problem was fixed -
Strip Linked Product - Debug - No, Release- Yes
Strip Debug Symbols during Copy - Debug - No, Release - Yes
Debug Information Format - Debug - DWARF, Release - DWARF with dSYM file
What got it to work was setting the Debug information format to "DWARF with dSYM File" for debug configuration as well.
My questions is - why do I need to to set the format to "DWARF with dSYM File" if I am specifying that the product should not be stripped of its symbols into a dSYM file (in the strip linked product setting)?
My (probably incorrect) understanding was that if I set it to DWARF, then all the debug information would be inside the app binary and I do not need a separate dSym file for symbolication? Please help me with a better understanding of this.
On Apple's platforms, DWARF is never baked into the executable (except for unwind info). Enabling DWARF debug info just means that the .o files contain DWARF-formatted debugging info. The linker doesn't bring that into the executable, though.
If you request a dSYM file, a separate build step uses dsymutil to collect the debugging info from the .o files into a dSYM bundle or file.
Debuggers can use a map in the executable to look up the debug info in the .o files when needed, assuming you're debugging on the build machine. That's why you don't typically need a dSYM file for a Debug build. Symbolication doesn't have the executable, just a UUID for it. It could find the dSYM using the UUID, but it doesn't have the information to find the .o files.
See this answer by an Apple developer involved in implementing this stuff. Also, this older wiki article he wrote.