What's the difference between DWARF and DWARF with dSYM file?

XCode supports those 2 values for this Build Setting:

Build Settings > Build Options > Debug Information Format.

Could anybody explain the differences?


Solution 1:

The difference is that in the case of DWARF with dSYM file your Archive app.xcarchive (for adHoc distribution) contains also dSYM file needed for reverse symbolication of your code in crash reports. In general, .xcarchive contains

dSyms
Products
info.plist

So if you need it for external analysis of crash reports under archiving you app for distribution you should use DWARF with dSYM file.

Solution 2:

As always understanding the abbreviations help!

DWARF is a widely used, standardized debugging data format:

DWARF was originally designed along with Executable and Linkable Format (ELF), although it is independent of object file formats. The name is a medieval fantasy complement to "ELF" that has no official meaning. Only that both (dwarf and elf) are mythological creatures

Debug Symbol (dSYM):

By default, debug builds of an application store the debug symbols inside the compiled binary while release builds of an application store the debug symbols in a companion dSYM file to reduce the binary size.

The Debug Symbol file and application binary are tied together on a per-build-basis by the build UUID. A new UUID is generated for each build of your application and uniquely identifies that build. Even if a functionally-identical executable is rebuilt from the same source code, with the same compiler settings, it will have a different build UUID.

For example, if you have a library libfoo.dylib, the debug symbol file would be libfoo.dylib.dSYM.

From here

So long story short

  • DWARF is just a debug file

  • DWARF with dSYM File is a debug file along with symbolification file


Pro tip:

On our project's GitHub repo, on the releases section we have something like this:

enter image description here

We upload the .ipa and dysm file so then if 3 months from now a user has a weird crash for our 10.16 build then we'd go to this release branch and run it with this dsym and try to reproduce the issue.