Fabric requesting dSYM that's not in archive or iTunes Connect dSYM file

You're almost there when you download the DSYM package from iTunes Connect! After downloading, add a .zip extension, and double click to unzip it.

In the folder of DSYMs produced, there will be one titled 65cbd90a2b443d36ab7a6a419b797a71 (the one Crashlytics is asking for). If it's not there - double check you are looking at the same builds on Crashlytics and iTunes connect.

Upload just that file to Crashlytics.

Problem solved. 👍

For non-Bitcode enabled apps, Crashlytics will automatically upload your dSYMs. If you have enabled Bitcode in your app then you need to upload dSYMs Manually.

Bitcode enabled applications are required to download their dSYM from Xcode and then upload it to Crashlytics in order to symbolicate the crashes. DSYMs for Bitcode enabled apps can be downloaded from Xcode’s Organizer. Select the specific Archive of your app and then hit the “Download dSYMs” button which will insert the Bitcode compiled dSYMs into the original Archive.

Uploading dSYMs Manually

If you find that dSYMs aren’t being picked up, you can add them manually by going to your app settings page, selecting an app, and click on the “Missing DSYMs” tab to upload the dSYM.

To help find where the dSYM is located, run this command in an open terminal:

mdfind "com_apple_xcode_dsym_uuids == <UUID>"

To find all dSYM try

mdfind "com_apple_xcode_dsym_uuids == *"

Also, if you upload a dSYM to Fabric, you should check that the UUID matches the one that is missing. Running this command in an open terminal will give you the UUID of the dSYM.

dwarfdump -u <PathToYourAppsDsym>

Reference

Crashlytics Advanced Setup

When you create a binary, the symbols are located at specific locations inside the file. When there are no symbols, the crash log will indicate offsets from certain points in the binary e.g. someFramework.someFunction +100

So a dSYM file is created to help index inside that specific binary. Re-archiving a modified code base or project will result in different offsets inside the new binary, so you cannot simply re-archive and upload.

This is why tagging your git repo with e.g release-v2.1 is important, so if you needed to you could go back and re-archive and the offsets should be the same.

As far as Fabric works, it requires a zipped version of the dSYM file, that number you posted is probably a hash of the zip file, I'm not 100% certain.

If you have the Fabric app installed on your system, running a version on the device should cause an automatic upload of the dSYM file (which can destroy upload bandwidth if you repeatedly build and run a project, where it will still upload each dSYM file per build).

You're best option would be to find the exact point in time in your git repo, and rerun the app in the simulator, this should upload the dSYM and hopefully pair to the old one, although I'm not sure it will work. Otherwise, if you think you have the exact dSYM, try zipping it and uploading it.

If that doesn't work, you will have to go the old-school way and re-symbolicate it manually using the terminal and the offsets in the crash log. It takes a bit of time, but its doable using atos

atos [-o AppName.app/AppName] [-l loadAddress] [-arch architecture]