7

I know that dSYM files are useful to have when you generate the final version of your app for the app store, because they will have the debug symbols that are used to symbolicate the crash log.

My question is if they are necessary during develop time. I ask this because by disabling them compiling time drops by 75%.

sepp2k
  • 363,768
  • 54
  • 674
  • 675
Duck
  • 34,902
  • 47
  • 248
  • 470
  • Do you use the debugger? – zaph Jul 05 '15 at 13:26
  • why? I have them disabled right now and I am still able to use the debugger. – Duck Jul 05 '15 at 14:09
  • I guess I am looking at something different. Wondering what setting are you changing? – zaph Jul 05 '15 at 14:20
  • [this one](http://imgur.com/8Zsh9kW). By changing that to DWARF only without dSYM, compile time drops by 75%. – Duck Jul 05 '15 at 14:29
  • 1
    There is one use-case I've found for (temporarily) changing the Debug symbol format (back) to _DWARF with dSYM File_ — when you're profiling your app in Instruments, and you've changed your target scheme's Profile settings to use Debug builds. | _Why would you do that?_ I've found the CPU usage (via the Counters instrument) source code annotations in Instruments to occasionally be incredulously misleading, reporting heavy activity on basic getter calls or unrelated run-only-once initialization statements. Changing to Debug (or reducing the optimization of Release) will give you the true story. – Slipp D. Thompson Nov 08 '16 at 01:00

2 Answers2

11

First off, to avoid some confusion: the default debug info format for the Debug configuration for new iOS projects is "DWARF with dSYM file", but for new OS X projects is just "DWARF".

Part of this is historical, but at present, the iOS setting is still "DWARF with dSYM file" only because the part of Xcode that symbolicates crash logs as they are copied off iOS devices uses the dSYM for that purpose. So if you are planning to test your Development build downloading it to the device, and then finger-launching and exercising it outside the debugger, then having the dSYM is handy for understanding any crashes you run into. If you're running under the debugger, of course, it will just stop at the point of the crash, so you don't need to symbolicate a crash report.

Other than that, I don't think you lose anything switching to DWARF for iOS. And as SpaceDog noted, it does speed up turn around time since the debugger knows how to lazily link up what DWARF it needs, whereas the dSYM creation tool (dsymutil) has to read & rewrite it all.

Of course, when you do a Release build you want to make & archive the debug information - which is the whole point of the dSYM, since otherwise the debug information (contained in the .o files) will get deleted along with the other intermediate build products and you won't be able to symbolicate crashes that happen in your released app.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • I saw somewhere that the debug info is contained in the mach-o file,dSYM just extract the file from it, is this right? – Karl Jun 24 '16 at 05:34
  • That's mostly correct, though it isn't a simple copy from .o file to dSYM. When the linker builds a binary image, it can reorder functions from the way they are in the .o files, and dead-code strip, etc. The information about those transformations is written in a "debug map" in the binary. dsymutil uses that debug map to "link" the .o file debug information as it is copied the dSYM. – Jim Ingham Jun 24 '16 at 22:26
  • wonderful answer! thanks.When we want to download a version to the device and "finger launch" it (that's what QA does most of the time) we hand them a Release build anyway - to which we have the DSYM. – Motti Shneor Jan 16 '17 at 13:29
2

You only want DWARF for development and DWARF with dSYM for release.

A new project comes defaulted to this configuration>

enter image description here

Also See this SO Answer.

Community
  • 1
  • 1
zaph
  • 111,848
  • 21
  • 189
  • 228