How to fix the missing dSYMs on Firebase Crashlytics
Getting started
If you are using some crash report providers such as Firebase Crashlytics or Sentry for your App, have you ever seen any issues like “Missing dSYM files” ?
I bet you have done! Well, there’re some reasons cause the dSYM files couldn’t be uploaded to Firebase Crashlytics completely, in this case we have to manually upload the missing dSYM files by ourself to fix the issue.
Why do we need to fix this? The missing dSYM files cause the Firebase Crashlytics cannot process your crash report, it needs dSYM files to symbolicate the crash report from memory addresses to human-readable informations, for example what is function name, file name or the number line causes the crash.
Bitcode disabled
If your app disables the Bitcode setting then you have to add a build phase script to upload the dSYM files automatically. Somehow, this step misses some dSYM files, we have to find the missing one then upload it manually.
First of all, you have to remember the UUID of the missing dSYM file, better to save it somewhere:
Now, we start finding this missing file! This step requires the archived file of your App version. If you archive & upload the archive from your machine then we can easily find it in: Xcode > Window > Organizer > Archives.
Next, choose an Archived version which matches the UUID’s App version on the Firebase Crashlytics. Extract its content to find the dSYMs folder
Now, find the missing dSYM file here by the name we got from the first step
Sometime, the dSYM file name is not UUID but binary name. To get the UUID of a certain dSYM file, use this command: dwarfdump -u <dSYM_file>
After finding the file, follow this step from Firebase crashlytics to upload it manually. Wait for few minutes to let Firebase crashlytics re-process the crash reports again then the issue would be dismissed.
If you’re using CI/CD providers to build & deploy the archive then remember to save it on their server, most providers support this purpose.
Some providers such as Bitrise already separated the dSYMs folder so we can use it directly! Do the same things above to find & upload the missing dSYM file.
Please remember: Always save your archive files!
Bitcode enabled
For App with Bitcode enabled, the dSYM files on the Archive’s dSYMs folder would be re-built on the Apple Connect server then we cannot use & upload them to Firebase Crashlytics. We have to wait until Apple finishes processing then would be able to download it from Apple Connect
After downloading them, we can follow the manual step from Firebase Crashlytics to upload them. Luckily, we can use this Fastlane’s download_dsyms plugin to download & upload them automatically, it saves a lot of time for us!
If you can find the missing dSYM there, you can upload it again to fix the issue.
Sometime, Apple Connect returns some wrong UUIDs, it means the user crashes on a binary has a missing UUID but Firebase Crashlytics received the dSYM of the wrong UUID so they cannot link together and cause the issue.
Firebase Crashlytics doesn’t display the binary name so it would be troublesome for us to find it manually. For some crash report providers such as Sentry, it can display the binary name of the missing dSYM file
Luckily, I’m using both of Firebase Crashlytics & Sentry so I can easily determine the binary name base on the missing UUID then find the wrong dSYM file in the downloaded dSYM folder from Apple Connect.
I hope Firebase Crashlytics would support this helpful feature soon!
“Cook” the dSYM file
In some cases, we make sure that we found the missing dSYM file but difference UUID, Apple Connect returns wrongly as we discussed above for an example.
One more use case is when you have to re-generate the binary & dSYM file from the same source code but the UUID of dSYM will be difference for each build time. Because our users are reporting on the missing UUID dSYM so we have to rename our UUID of dSYM.
This step looks like we’re “cooking” the missing dSYM file!
⚠️⚠️⚠️ You MUST BE careful about this step, if you “cook” the wrong one, the crash reports would be messed or unreadable!
Hope you beware what you’re going to do! To do this, open the DWARF file from our dSYM file: <my_uuid.dSYM>/Contents/Resources/DWARF/<my_binary>
You can open this DWARF file by Visual Studio’s Hex editor or any online hex editor tools. I’m using https://hexed.it to find our current UUID & replace it by the missing UUID on the Firebase Crashlytics. For my experience, searching for first 4 characters of UUID is better than searching for all UUID
After replacing, save and download the file, then replace the original one. Now upload the “cooked” dSYM file to Firebase Crashlytics then the issue would be solved!
Can’t find the UUID by the Hex editor tools? You can try this command-line tool: https://github.com/schmittsfn/dsymrename
Conclusions
In this article, you learned how to find, “cook” & upload the missing dSYM to Firebase Crashlytics, this approach can apply for other crash report providers as well.
Please remember always store the archives for non-bitcode app on your local or CI server and beware what’re you doing while “cooking” the dSYM file!!!
