Requesting additional information with MXAppExitMetric payload.

Hi all, my company is looking more into MetricKit's MXAppExitMetric. The existing breakdown of exit reasons is very helpful but we are hoping to find a way to link these exits with a timestamp. This would help us to correlate app exits with other events that we are tracking on our side.

Are there plans currently plans to add more granularity to this payload? If not, how can I submit an official request to do so?

Replies

Are there plans currently plans to add more granularity to this payload?

Apple does not, as a general rule, discuss its future plans.

how can I submit an official request to do so?

By filing an enhancement request.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you! Bug number: FB13041946

Add a Comment

@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.

  1. 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
  2. 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
  3. 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.
  4. 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!