Manually Symbolicate Mac App Store Crash
• 2 minute read
If Xcode fails to automatically resolve frames in your crash reports of your Mac App Store app even though you have the original Xcode archive, this is how you can achieve it manually.
We have a macOS app in the App Store which occasionally has a few crash reports coming in. Even though I am abled to retrieve the crashes in the Xcode organizer and have the originally uploaded Xcode archive of that published app build on my Mac Xcode is not abled to symbolicate the frames of our code.
Also the “Open in Project…” option is of no use as it cannot resolve any of the missing frames in the call stack. I researched a bit and found various suggestions including one I knew from colleagues I worked with on a past project.
Having to symbolicate manually now, the most on how to that is described by Apple itself on the article of Adding Identifiable Symbol Names to a Crash Report. However I was missing the information of the load address of my app’s binary image.
After a bit of poling around I found out that the *.crashpoint-file is a document bundle. It contains a *.crash-file which offers more information than the Xcode organizer. It contains a section headed by “Binary Images” which includes the app binary image’s load address. With this missing puzzle piece the symbolication command in the Terminal can be completed like this:
atos -arch x86_64 -o Example.app.dSYM/Contents/Resources/DWARF/Example -l 0x10fefa000 0x000000010ff9ce9f
Note that I replaced our app name with “Example” here. The dSYM bundle name usually equals the app bundle name plus a “.dSYM” suffix. Also the binary image inside the “DWARF” folder equals the app name. The dSYM bundle for an can be found inside an Xcode archive (being itself a document bundle) in the “dSYMs” folder. I copied it into a dedicated folder and navigated there in the Terminal for clarity.