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?
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.
Related
XCode supports those 2 values for this Build Setting:
Build Settings > Build Options > Debug Information Format.
Could anybody explain the differences?
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.
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
DWARF is embedded in the object files of the binary, but not in the binary itself (unlike stabs, which are linked into the binary proper). dsym extracts the DWARF info from the object files, puts it in a separate dSYM bundle and makes the binary refer to this bundle (instead of to the object files). Docs
Also see DWARF's official home page
Pro tip:
On our project's GitHub repo, on the releases section we have something like this:
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.
Both DWARF and DWARF with dSYM create DWARF debug information like on all other platforms, but they differ on where the debug information will be accessed when debugging or symbolicating:
DWARF means that the debug information is left in .o files and this debug information is not linked during the build process. Each .o file will contain unlinked DWARF and the debugger (LLDB, GDB) will link the debug information on the fly when debugging. The main executable contains a debug map contained in the symbol table which has everything that is needed to link the debug information. The maps contains STABS symbol entries that points to each .o file and tells the debugger or linker where everything needs to be linked (for functions, globals and static variables). The debug information will be less efficient since it is not linked, and each .o file can contain type definitions that are also found in other .o files, so the overall debug information size will be bigger. This is often most useful for the edit/compile/debug cycles for when you're implementing new features or trying to track down bugs. The benefit is you do not have to link the debug information during your build process. Not all tools that parse debug information support this mode of debug information, so you might want create dSYM files if local crash reports on your system do not contain source file and line information in the backtraces. Tools like sample, ReportCrash, and Instruments that need to parse debug information might not support the DWARF setting.
DWARF with dSYM means that after you build your executable, a dSYM debug information file will be linked using a tool named dsymutil. dsymutil gets ran after your executable is linked to parse the debug map in the main executable and produce a dSYM file with all of the debug information. Linking the debug information can add to your build times if you have a lot of code in your project. The DWARF debug information in all of the .o files is intelligently linked into the dSYM file. Any code that was dead stripped will have its debug information removed, and the dsymutil will dedup types within the debug information, so the resulting DWARF is much smaller and more efficient. Use this setting when building your releases or if you have a build machine that is caching builds for others to download.
In order to find the dSYM file for an executable, the UUID from the main executable is copied into the dSYM file. A previous comment suggested that the UUID changes with each build even if the same source code and compiler was used, but this is not true. The UUID is a MD5 checksum of the parts of the binary that do not change due to debug information. Debug information can contain paths and other data that change depending on what directory the sources exist in. If the UUID was simply a MD5 checksum of the entire binary, then the UUID would be different for the same sources built with the same compiler if one was built in /tmp/myproj vs /users/data/myproj. So the UUID built into Darwin binaries will match if the important bits (__TEXT, __DATA, etc) are the same even if the project is built in different directories. This allows the UUID to be used to unique dSYM files across multiple builds that produce the same binary. If SDK header files or different compilers or linkers are used, the UUID can easily differ.
There is Spotlight importer for dSYM files knows how to extract the UUID from the dSYM file to make it possible for debuggers and other tools like sample, Instruments, ReportCrash and more to find the dSYM file for a binary even if the dSYM file is not right next to the binary. You can see the UUID of your binary by running dwarfdump:
$ dwarfdump --uuid ~/a.out
UUID: E76A2647-AFB4-3950-943A-CB1D701B7C07 (x86_64) ~/a.out
Then you can use the Spotlight window in your system to search for the dSYM file. There is also a command line tool for spotlight called "mdfind" that can be used:
$ mdfind E76A2647-AFB4-3950-943A-CB1D701B7C07
/Users/admin/a.out.dSYM
So to sum up: use DWARF for edit/compile/debug cycles if you have large projects and want to avoid the time it takes to link a dSYM file during your daily workflow. Use DWARF with dSYM all the time if you have smaller projects, doing release builds, or need other Apple tools that are not debuggers to be able to parse your debug information. Both formats contain the same kind of information and can be used for debugging, but not all tools can load the DWARF format where the DWARF is left in the .o files.
DWARF (debugging with attributed record formats) is a debugging file format used by many compilers and debuggers to support source-level debugging. It is the format of debugging information within an object file. The DWARF description of a program is a tree structure where each node can have children or siblings. The nodes might represent types, variables, or functions.
source: https://www.ibm.com/developerworks/aix/library/au-dwarf-debug-format/index.html
DWARF with dSYM File stores the debug symbols for your app
Services like crashlytics use it to replace the symbols in the crash logs with the appropriate methods names so it will be readable and will make sense.
source : What's the dSYM and how to use it? (iOS SDK)
From "Project Editor Help":
Debug Information Format (DEBUG_INFORMATION_FORMAT)
The type of debug information to produce.
DWARF: Object files and linked products will use DWARF as the debug information format. dwarf
DWARF with dSYM File: Object files and linked products will use DWARF as the debug information format,and Xcode will also produce a dSYM file containing the debug information from the individual object files (except that a dSYM file is not needed and will not be created for static library or object file products). dwarf-with-dsym
I have an iOS project. In response to Build (with a release configuration selected in the scheme) the dsym for it weighs in at 6.5MB. However, when I Archive (with the same configuration selected in the scheme) it weighs in at only 2.9MB.
This is not an academic problem. The missing data includes all the symbols for my static libraries, which is making my crash logs a lot less useful.
Which settings could account for a difference between a Build and Archive with the same configuration selected?
This is with Xcode 5.0, though I think I've been having this problem for a while.
I believe a few things it does are:
Remove all debugging symbols from the app to the .dsym file
Compresses various articles from ascii to binary (such as strings
files)
Some of the differences may be from the following build flags:
DEPLOYMENT_POSTPROCESSING=YES
STRIP_INSTALLED_PRODUCT=YES
SEPARATE_STRIP=YES
COPY_PHASE_STRIP=YES
For most of my projects, I setup an "archive" scheme to archive my project, creating an IPA and DSYM that I can upload to TestFlight.
However, I'm working on a more complicated project that has several targets within the project workspace, quite a few static linked libraries. I have gone through each target and set the following for all configurations:
Deployment Postprocessing -> NO
Strip Linked Product... -> No
Strip Debug... -> No
Generate Debug Symbols -> Yes
Debug Information... -> DWARF with DSYM
I am using Xcode 4.5.2. I have done this for multitudes of projects with no issues. This is the first where something seems to be preventing the DSYM file from being created.
No matter what I try, my archive build will not generate a .DSYM file
Identifying the problem
As #belsokar suggested, check the Report Navigator.
In my case, the dSYM file has not been generated, and there hasn't been a corresponding line that goes like "Generate Appname.dSYM ...in {path}"
But there's been Fabric installed, and it logged the fact of the dSYM file's absence:
Just filer the Report Navigator by "dSYM".
Fixing
In my case I've just had to do what I'm asked of:
DEBUG_INFORMATION_FORMAT should be set to dwarf-with-dsym for ALL
configurations.
Also, it may turn out that dSYM file is being generated in an unexpected place. Check environment variables, especially DWARF_DSYM_FOLDER_PATH and DWARF_DSYM_FILE_NAME.
To embed the dSYM within the app bundle, just set DWARF_DSYM_FOLDER_PATH to $(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_FOLDER_PATH) and DWARF_DSYM_FILE_NAME to $(EXECUTABLE_NAME).dSYM
Checking
Now the build should create dSYM for your target
xcode - > product -> Archive
you see Archives window
1 Select any Archives of your app Right click on it Then select show in finder
2 you see aapname.xcarchive file Right click on it and select show package contents
3 you see dSYMs folder open it and get .dSYM file
:)
Try using: Deployment Postprocessing -> YES
check this out: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html
A few tips for researching.
Check the Log Navigator. I went into this view (one I rarely use so I tend to forget it exists), and I realized the .DSym file was in fact being created.
Check build directory configs to see if they are default or custom...in my case, they were custom, so they weren't being put in the typical default location.
As mentioned in the main answer, the value of DWARF_DSYM_FOLDER_PATH determines where the dSYMs will go. The default value is $(CONFIGURATION_BUILD_DIR), so if you have a custom CONFIGURATION_BUILD_DIR setting, it can change DWARF_DSYM_FOLDER_PATH such that the dSYMs do not get copied into the .xcarchive. I have also found that a custom SYMROOT setting can also change the path, and possibly some other setting overrides as well.
Normally during an archive build, the CONFIGURATION_BUILD_DIR and DWARF_DSYM_FOLDER_PATH values will be somewhere under an "ArchiveIntermediates" folder, the contents of which presumably get copied to the eventual .xcarchive.
If you can avoid overriding those settings, that would likely be preferable, otherwise DWARF_DSYM_FOLDER_PATH may also have to be overridden to point to the correct location, or a post-build step would be needed to copy the .dSYM folders from wherever they ended up to the XXX.xcarchive/dSYMS folder.
DWARF_DSYM_FILE_SHOULD_ACCOMPANY_PRODUCT=YES copied the .dsym files to the archive in my project.
Also, I did not change the default DWARF_DSYM_FOLDER_PATH or DWARF_DSYM_FILE_NAME values.
This is work around helped me:
Log into iTunes Connect and go to My
Apps.
Click on the app that you're trying to download the dSYM for
Go to 'Activity' tab.
Click on the version you want to expand it and
show all the uploaded builds.
Click the build you want.
You'll be shown details about that build, and the option to download dSYM in the bottom right corner under 'Includes Symbols' header.
I am stripping symbols in Xcode 4.5, but realised that if we strip them we cannot symbolicate crash reports. So I am trying to create a copy of the unstripped binary before stripping. It seems this isn't possible with the normal xcode symbol stripping settings, so I've tried digging into run scripts. The problems I have there is
a) It seems the run script runs after code signing, so the app fails to run.
b) I can't find a way to run a run script under distribution/release only.
Any suggestions?
You can symbolicate crash reports when the binary is stripped! Stripping the binaries makes them 30-50% smaller. Symbolicating with unstripped binaries would not give you line numbers after symbolication anyway.
During the build process you also get a dSYM package which is then used instead to symbolicate your crash reports including getting line numbers in them!
In addition, whenever you do a new build, you get a new unique pair of app binary and dSYM package, so you should use archive instead of build when you are releasing a beta or production version.
I've written an iPhone application and I'm planning to open source it. I'm concerned about distributing the source and making sure I get only the required files distributed. I'm also concerned that since I've signed my app for distribution on the AppStore that open sourcing the project would possibly expose some part of the singing certificates.
Is there an accepted practice for what to distribute? I was going to exclude the build directory but wanted to included what was required for anyone to easily open and build the project. I tried this as a test by copying all but the build folder and was able to open and build the project from the copy which didn't contain the build folder so that seems fine.
I guess the bottom line is can I safely distribute the entire project minus the build directory or are there things embedded in the project files I'd want to exclude beyond the build directory?
Thanks for any responses I'm pretty new to xcode
The Code Signing Identity setting (of either your project and/or target) sometimes contains your name (or your organization's name).
So I'd clear out that setting (in all configurations) from the project file.
All the really sensitive items (e.g., your private key) are kept in the OS X keychain, not in any project files.
Inside ProjectName.xcodeproj, you'll find project.pbxproj and some other files. You only want to distribute project.pbxproj, the other files are specific settings for you/your computer. Also, project.pbxproj is just a text file. You can take a look inside and see what you're giving out.