5

Since I use Crashlytics to handle my crashes, I always uncheck the “Include app symbols for your application to receive symbolicated crash logs from Apple” and keep the "Include Bitcode" one checked (future proof for Apple Watch) before submitting my app to iTunes Connect like this :

Settings

Crashlytics has an article about issue with Bitcode and missing dSYMs :

https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#bitcode-download

According to their screenshot, to download the new generated dSYM file created by Bitcode, there is a download link available directly in iTunes Connect, BUT, it seems that you must have checked "Include app symbols" to be able to download them, otherwise you simply get this:

No

So I'm a bit confused on how these two settings are required for the well-functioning of Crashlytics or any 3rd party crashes handler service.

Should I keep both settings checked? Is it OK to uncheck "Include app Symbols" since I don't use Apple's Crash organizer (from my understanding, dSYM files are uploaded to Crashlytics during their post-script archive) and only keep Bitcode checked or if I do that I won't be able to download new Bitcode generated dSYMs (causing problems to Crashlytics symbolize crashes correctly)?

allaire
  • 5,995
  • 3
  • 41
  • 56

1 Answers1

10

This is a good question. There are numerous knobs that affect the availability of debug symbol information for your app. It's confusing, and people are constantly tripped up by it.

Here are my guidelines:

  • always check the "include symbols" box when submitting apps to Apple
  • always strip your final executables (.app, .framework)
  • never strip your static libraries, if you have any
  • you want Apple's crash reporting to work, even if you don't plan to look at it

With this configuration, your dSYMs, produced locally or by Apple, will contain the debug information necessary for both Crashlytics and Apple's reporter to work. It is critical you share symbols with Apple when using bitcode. If you do not, it is likely you will never be able to see symbolicated crashes for that version of your app.

There are, of course, some valid reasons why you might not want to share symbols with Apple. One is you want to obfuscate your code. I'm aware of a few apps that do this. Of course, this is a trade-off, because it makes symbolication much harder, or even impossible, depending on the obfuscation system.

There are also reasons why you might not want to strip your executables. One is that you rely on a 3rd party crash reporting system that does not support server-side symbolication. This is less and less common, as far as I know, but it is something to be aware of.

Finally, you definitely do want Apple's crash reporting system to work, even if you never plan on using it. Apple's system is able to capture more crashes more reliably than any 3rd-party solution could. I'm sure it is also invaluable for Apple's internal work. It definitely does have limitations, but really doesn't cost you anything. So, keep it working, if for no other reason than to have the option to look at it in the future.

Mattie
  • 2,868
  • 2
  • 25
  • 40
  • 1
    I should have also included a link the the Fabric decimation covering this general area: https://docs.fabric.io/apple/crashlytics/missing-dsyms.html – Mattie Oct 04 '16 at 13:34
  • Thanks Matt! I was unchecking the "Include Symbols" checkbox because I was getting some "rsync" error, and it took sometimes 2-3 times to successfully upload. I also saw a Github issue where Fastlane developer says he was unchecking it since he was using Crashlytics. – allaire Oct 04 '16 at 13:48
  • Funny thing is I cut many release with that checkbox off, and Crashlytics was correctly receiving my symbolicatedcrashed. Is it because my app was (yet) not recompiled by Bitcode, and it was still using the same dSYM file that was uploaded to Crashlytics during the archiving phase? – allaire Oct 04 '16 at 13:49
  • 2
    You got it. Sharing symbols with Apple is only necessary when using bitcode. Debug symbols need to be represent on the system generating the dSYM. So, when that was happening on your machine, things were ok for Crashlytics. Apple's reporter would still be compromised, though. There are basically no good reasons for unchecking that box (flaky uploading notwithstanding). – Mattie Oct 04 '16 at 14:09
  • I am trying to upload the symbols but I cannot find the upload-symbols script. I have used cocoa pods to get Crashlytics and the only script available is the uploadDSYM script but that gives me this error when I try to upload the dSYMs : `warning: using uploadDSYM directly to upload dSYMs is not supported. uploadDSYM will be deprecated in a future release.error: Fabric: Failed to Detect Build Environment` – RPM Nov 11 '17 at 00:53
  • Unfortunately, I'm no longer at the company that maintains Crashlytics. But I had a quick look at their documentation page, and it looks like it has helpful information: https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#upload-symbols-script – Mattie Nov 16 '17 at 20:25
  • I found the script under the Fabric cocoapod. I was looking for it under the Crashlytics cocoapod previously. I uploa my dSyms but it still has issues - I see the __hidden in the stack trace which is not helpful at all. – RPM Jan 26 '18 at 00:07
  • 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:32
  • @JamshedAlam you should contact the Crashlytics support support team. They'll help you out! – Mattie Apr 23 '18 at 15:18