ioscrashlyticstestflightdsym

iOS: Why is Crashlytics saying there are optional dSYMs to upload when everything should already be uploaded?


When an app is uploaded to Testflight, previously there used to be an option to recompile bitcode, which if clicked would mean new dSyms would also get generated and need downloading from Testflight. However that option has now gone, meaning the dSyms produced locally on your build machine can be uploaded to Crashlytics and there's no need to download any dSyms from Testflight.

So I've built an archive and within it I can see the dSyms, which all have human-readable names, such as myApp.dSym or myNotificationServiceExtension.dsym etc. and I've uploaded these to TestFlight, and they're working because I can see symbolicated crash reports in the Crashlytics console.

So why therefore is Crashlytics reporting that there are some optional dSYms to upload? And why do they have hex names not human readable names?

i.e. Crashlytics is saying these dSyms are missing for the build/release:

7209F7CE-3E45-3321-8B0B-41F0FCB53847 4.0 (5) Optional 702
624A5CE2-ED62-367D-B415-CBA2219953CE 4.0 (5) Optional 665
0CB9EBB4-17EB-386B-B1E0-4CEA7F3CA5AF 4.0 (5) Optional 511

If I've already uploaded all the dSYms that were created during the build, and TestFlight didn't additionally create its own set of dSyms (because there is no option to rebuild on upload anymore), then what are these dSYms that Crashlytics is saying are not uploaded?


Solution

  • There are two types of dSYMs:

    One possible reason for this is if the included binaries from .frameworks being used have stripped symbols.

    The hex name you mentioned is a UUID. These are assigned to all the dSYMs and builds and is how you can match a crash report against the symbol files. I.e. This is the only thing available to Crashlytics in the device that can be related to a symbol file.