64

I'm working on an app with another developer and they just submitted a release to the app store that was built on their computer. In order to make a build on my machine (that belongs to the same git commit), I have to alter the path to one of the libraries we use in my XCode project. Will any changes I make to the XCode project file change the dSYM? If I was able to make a build without modifying the XCode project file, would the dSYM file be the same?

couchy
  • 669
  • 1
  • 6
  • 5

1 Answers1

149

A dSYM file is a "debug symbols file". It is generated when the "Strip Debug Symbols" setting is enabled in the build settings of your project.

When this setting is enabled, symbol names of your objects are removed from the resulting compiled binary (one of the many countermeasures to try and prevent would be hackers/crackers from reverse engineering your code, amongst other optimisations for binary size, etc.).

dSYM files will likely change each time your app is compiled (probably every single time due to date stamping), and have nothing to do with the project settings.

They are useful for re-symbolicating your crash reports. With a stripped binary, you won't be able to read any crash reports without first re-symbolicating them. Without the dSYM the crash report will just show memory addresses of objects and methods. Xcode uses the dSYM to put the symbols back into the crash report and allow you to read it properly.

Ideally, your dSYM file shouldn't be tracked in your git repo. Like other binaries that change on building, it's not useful to keep them in source control. However, having that said, it is important that you keep the dSYM files for each distributed build (betas, press releases, app store distributions, etc.) somewhere safe so that you are able to symbolicate any crash reports you might get. Xcode does this automatically for you when you use the Archive option. The created archive contains your app and its dSYM and is stored within Xcode's derived data directory.

Mike
  • 4,550
  • 4
  • 33
  • 47
Jasarien
  • 58,279
  • 31
  • 157
  • 188
  • 39
    One addition: dSYMs and executables have an embedded UUID which matches. So every time a build is done will cause both to get a new UUID. 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. – Kerni Mar 17 '14 at 17:05
  • 3
    Great answer here from Jasarien. I will just add that using "Archive" these days stores all of this neatly inside a folder in your Xcode directory. You can right-click an archive in your Organizer of Xcode and "Show in Finder". But for completeness I will add that my folder exists in ~/Library/Developer/Archive – bladnman Dec 29 '14 at 18:00
  • Another setting is "Generate Debug Symbols" – onmyway133 Mar 01 '16 at 11:10
  • 4
    I'm a bit confused... You say "Strip Debug Symbols" needs to be enabled (set to "YES") in order to be generated? And yet underneath, it says that if the setting is enabled, the names of objects are *removed*... So, if I want to see my symbol names in Instruments, should this setting be set to "YES" or "NO"? – jowie Mar 14 '16 at 10:58
  • 3
    As a rule of thumb, for debug builds, `Strip Debug Symbols` should be `NO`, so that the debugger is able to display all of the symbols. Release builds should have it set to `YES`, which removes the symbols from the binary, creating the .dSYM file to put them in. So when profiling, you should decide which configuration you'll use, if you need to see the symbols, then use a debug config so they're available - if you need to profile performance, probably best to use a release config. – Jasarien Mar 14 '16 at 12:24
  • @Jasarien the compiled binary is actually a fat binary containing all the builds for all the supported architectures, so a dSYM file contains the symbols for all these builds? – onmyway133 Apr 04 '16 at 20:14
  • 1
    Another setting that seems be needed for full symbolication in, e.g., local debug builds appears to be: _Build Settings_ › _Build Options_ › _Debug Information Format_ › _DWARF with dSYM File_. Just like for release builds. – B98 Jun 21 '16 at 12:44
  • Dear @Kerni why is there many UUID files while the symbols for one archive should be in one file, i have noticed that they are ony created when i use "download dSYMs" which downloads them from itunesconnect i suppose. – SoliQuiD Dec 30 '17 at 12:06
  • 1
    @SoliQuiD When you build apps with Bitcode enabled, they get re-compiled on Apples servers optimized for different CPU architectures which results in a new set of symbols with a new UUID for each CPU architecture. The process is probably asynchron in some way so that there is not easy way to combine them into a single file. There is no real requirement to have one file for those anyway. – Kerni Jan 01 '18 at 14:18
  • @all : I set both DEBUG DWARF with dlsym file. When I upload dsym from Xcode finder , it provides me a debug dysym and I upload it to crashlytics, test crash, I get crash on dashboard. But when i download the dysym from iTunes and upload to crashlytics, it's not showing crash. I set Selected symbols always, enabling bitcode! What can I do ? – Jamshed Alam Apr 11 '18 at 06:38
  • Agree with @jowie. The "Strip Debug Symbols" is a bit misleading. Xcode 10.3 Organizer gives (i) "Strip Swift Symbols" to remove the standard libraries' symbols and (ii) "Upload your app's symbols...." and Build Setting has "Strip Debug Symbols During Copy" – eharo2 Jan 16 '19 at 17:26
  • Does this mean that it is impossible to regenerated a deleted dsym by rebuilding? – Bradley Thomas Mar 09 '19 at 22:49
  • Are dsyms generated upon enabling: "Strip Debug Symbols"?! or it's just that they're stripped from the app's binary? And you must set 'debug information format' to 'DWARF with dsym file'? – mfaani Jan 17 '23 at 19:58