iosapp-storecrashlyticsgoogle-fabricdsym

Dealing with missing dSYM files in a black box situation

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.sstatic.net/QSFoy.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.sstatic.net/qFzN8.jpg

So... I'm in a black box situation here...

My questions are:

  1. Why were the other two dSYM files not in the zip I downloaded form the App Store?
  2. 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?
  3. 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.

Solution

  • 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.