@joshmooredd
TLDR: Start using MXCrashDiagnostics
contained within the MXDiagnosticPayload
. This has timestamps of crashes.
If you're looking for exact timestamps, you might be able to discern some of them by looking at the MXDiagnosticPayload
and the resulting MXCrashDiagnostics
within. If however, you are just looking for ORDER and relative time, then you can build this out yourself with a few different techniques. Meaning if you just care about timeline and sequence of your events intermixed with exits--check out the following recommendations.
- Use official Apple API to detect TERMINATIONS (by the user). See: UIApplicationDelegate - applicationWillTerminate You're not guaranteed to get this callback, but when you do, expect it to show up in exit data later on in the metric payload
- Use a signal handler to inspect uncaught exceptions. Not for the faint of heart. If you're only looking to make breadcrumbs and NOT capture things like call stacks at the time of an uncaught exception, this might be an okay thing to do. Look at ANY of the shelf open source crash reporting solution for examples. BUT, also heed the words of @eskimo here: Implementing your own crash report
- If you're just worried about order, start looking at the crashes found in the
MXDiagnosticPayload
. They will contain a timestamp of when the crash occurred and then you can build your timeline. Some of the MXCrashDiagnostic
might have easy to map exceptionType, exceptionCode, and bsd signals that you can map to the exit data counts. - If you're targeting iOS 17, PID to the rescue. I asked in feedback to add some identifiers to be added to the payloads, and as a response I got PID in the metadata (big thanks MetricKit team!!! FB9616844). IF your events were capturing
PID
, hint look at ProcessInfo
, you could know for certain which crashes were in which run of the app with respect to your events. Then use this info and combine it with suggestion 3.
Hope this helps you on your journey to making better apps!