Several companies (Crittercism, Crashlytics, Hockeyapp and others) offer crash symbolication services for iOS. These require one to upload your apps dSYM file/folder but they don't ask you to upload the associated App file.
Symbolicatecrash, ATOS and related tools all seem to require both the APP and dSYM files to symbolicate a crash. How do they get around this requirement?
The app binary is not used or required for the actual symbolication process. The symbolicatecrash script from Xcode is requiring the app binary to be available but actually never uses it. It is not documented why the script requires the binary to be available though. You can verify this yourself by opening the script (it is written in Perl) in an editor.
Related
Our application has bitcode enabled, so we can't use dSYM files generated on our machines/CI but rather we should use dSYM generated during bitcode compilation. The problem here is that we don't have those files available to download on App Store Connect (no link is presented).
That's really weird. We suspected that maybe our 3rd party tool which we upgraded recently and that is used to obfuscate our binaries started to work incorrectly but all builds get "Validated" status and we can publish them in App Store without any issue.
I suppose that bitcode process runs correctly as we get smaller binaries available in App Store, but dSYM is somehow not produced.
I found a thread on Apple Developer Forums but nothing really uncovers the root of this issue: DSYMs No Longer Offered for Download?
We are trying to address a critical crash in an iOS application that's using Fabric / Crashlytics. We don't have the contact details of the person that was last working on the application and uploaded the latest version to the App Store.
In the project dashboard I noticed the message "Found XXX unsymbolicated crashes from missing dSYMs in 1 version in the last 24 hours". Screenshot: https://i.imgur.com/YT9gggJ.jpg
I did the only sensible thing I could think of: I went to the App Store Connect dashboard. I downloaded the dSYM zip for the build in question as per the official instructions from Fabric: https://docs.fabric.io/apple/_images/download-dsym.png
I then went to the dSYM tool and uploaded the zip directly. Turns out only two of the four files required were in the zip (I also examined it myself): https://i.imgur.com/JqxZcaD.jpg
So... I'm in a black box situation here...
I'm not an iOS developer
I don't have access to the computer used to build the project or the person that produced the build
I'm assisting an iOS developer that has just joined the team
I have access to the project repository
I have access to the App Store Connect profile
I have admin access in Fabric
My questions are:
Why were the other two dSYM files not in the zip I downloaded form the App Store?
Why are some crashes associated with one dSYM and the rest to another? Is there any sort of categorization of the crashes that we currently have access to?
Can we do something to gain access to all the production crash reports without publishing a new app version to the App Store? We're trying to avoid this scenario ATM.
EDIT #1:
So this person that published the build was not exactly following best practices. I wanted to explore the possibility of them having the dSYM files committed to the server repo.
This is their gitignore:
.DS_Store
xcuserdata
<PROJECT NAME>.xcodeproj/project.xcworkspace/xcshareddata/
build/
Build/
I guess the build folder pretty much rules out this possibility. I also searched the file structure for files containing the text "com_apple_xcode_dsym_uuids ==" with no success...
EDIT #2:
I'm appending an exceprt of the answer Fabric support gave me:
If your application is using frameworks, the product folder will have
a separate dSYM file generated for each framework built. Eventually
all of them are needed if we want to cover our bases and be able to
symbolicate a crash in every possible location in our app. A dSYM file
generated while building a specific version of the application can
only be used to symbolicate crashes from that specific version only.
dSYM files are identified by a Unique ID (UUID), which changes every
time we modify and rebuild our code, and that ID is what is used to
match a symbol file to a specific crash. A dSYM may be associated with
more than one UUID, as it may contain debug information for more than
one architecture.
It looks to me that you may need to upload a new build, which is not too bad after all if it includes any bug fixes. Regarding your questions:
Why were the other two dSYM files not in the zip I downloaded form the App Store?
The option to download dSYMs from App Store connect is available only if the app was distributed using Bitcode. Bitcode is intermediary representation of the source which App Store uses to produce the final optimised machine code targeting specific architecture/device. When Bitcode is selected all linked frameworks/libs should also be delivered using bitcode, so it looks weird to have only some dSYMs. Although unlikely, is it possible that the missing dSYMs are from another build?
Why are some crashes associated with one dSYM and the rest to another? Is there any sort of categorization of the crashes that we currently have access to?
Each target/framework/lib generates its own dSYMs, so your app probably depends on one or more frameworks and some of the crashes originate from that frameworks.
Can we do something to gain access to all the production crash reports without publishing a new app version to the App Store?
I can't think of another solution so far.
Question #1:
I am using Crashlytics for one of my commercial iOS Apps. Their service seems very helpful. I wonder if there is any Legal issue of using their services for commercial apps? Is there any limitations for using Crashlytics?
Question #2:
I need to upload .dsym file in their server to get crashlogs symbolicated. Is there any privacy issue. Is it possible to get my code (or any info) back by reverse engineering when they have .dsym file.
Question #3
Sometime some crashes are not showing in the crashlytics dashboard. Is it necessary to be online when crash happens to get crashlog in dashboard? Don't Crashlytics keep logs trace when offline and send logs back to the server when device become online? Any idea how they work?
Mike from Fabric here, but I'm not a lawyer.
1) Fabric and Crashlytics is used in many commercial apps, including our own. There aren't limitations to using Fabric. You can find the Fabric terms of service here.
2) The dSYM is what let's us or any other crash reporter symbolicate the crash report as it contains the symbols that map back to your app's source. None of your source code is uploaded. From Apple's own documentation:
As the compiler translates your source code into machine code, it also
generates debug symbols which map each machine instruction in the
compiled binary back to the line of source code from which it
originated. Depending on the Debug Information Format
(DEBUG_INFORMATION_FORMAT) build setting, these debug symbols are
stored inside the binary or in a companion Debug Symbol (dSYM) file.
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.
3) Crashes are caught regardless if the app is connected to a network or not. However, crashes are only sent on relaunch of the app and would then be processed.
One thing to note is that if you're testing in the Simulator or with your device connected to Xcode will cause Xcode's debugger to capture the crash instead of us.
Further, if the dSYM hasn't been uploaded, then we're unable to process the crash report and we'll alert you in the Crashlytics dashboard of the missing dSYMs so that you can upload them.
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%.
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.
You only want DWARF for development and DWARF with dSYM for release.
A new project comes defaulted to this configuration>
Also See this SO Answer.
I've been getting a bunch of crash logs for my (largely c++) app on iOS. My problem is I can't seem to ever symbolicate these crash reports properly.
What is the "proper" setting for stripping debug symbols for release on iOS? I get that you'd want to strip the debug symbols so the download size of the app isn't ridiculously large.
But the problem is that it seems to make the crash reports virtually unreadable.
Do dSYM files on the xcode archives get sent and eventually downloaded by the users?
Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on xcode)?
Or is it simply something to be kept for future symbolicating purposes (done locally on my own machine, on Xcode)?
This. Your "release" config (or whichever config you use for distribution) should have the following setting:
Symbols Hidden by Default: Yes
Xcode will still generate a dSYM folder which is what you will use for symbolicating crash logs. There are 3 ways to handle symbolicating:
Use Xcode. For this you need to use the Product -> Archive feature whenever you release. Once an archive is created, you can select "Export" then "Save for iOS App Store Deployment". After this you can drag crash logs into the left side of the "Device Logs" window and Xcode will symbolicate them for you.
Manually symbolicate using the symbolicatecrash tool located inside your Xcode.app folder. This is useful if you've released code to users but don't have an Xcode archive. You need to be sure that the crash log matches the binary and dSYM or it will not work.
Use a third party tool that collects crash reports and symbolicates them for you. Examples include Crashlytics, Bugsense, or HockeyApp.