I wrote a python script called MXSymbolicate (https://github.com/OliveTreeBible/MXSymbolicate) to symbolicate the crash reports produced by the old version of MetricKit. The new MetricKit in the '27 releases appears to be basically the same data but in type-safe form, with the addition of state tracking. Notably, the new CrashReportExtension API seems to include the ability to symbolicate a crash stack on-device, but it looks like the CallStackTree type is still just binary names and frame offsets and such - no symbol names.
Should I keep symbolicating crash reports from the new MetricKit APIs the same way I did the old ones? Or is the expectation that I should use the CrashReportExtension system for symbolicated crashes, and use the MetricKit crash reports for other purposes, like state tracking?
CrashReportExtension and MetricKit perform very different functions, but in terms of symbolication I don’t think there’s any need for you to make a change here. In general, it’s better to symbolicate off device, which means recording a list of Mach-O image UUIDs and load addresses. MetricKit gives you that, so there’s no reason to deal with the complexities of CrashReportExtension.
CrashReportExtension makes sense if you want to do something much more custom, for example, if you want to reach into the corpse (ewwww!) and extract state that’s not available in the standard crash report given to you by MetricKit.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
