MetricKit support for Firebase Performance on iOS 13+

[jlaws]

It would be great to have automatic reporting of data provided by Apples new framework MetricKit

[zdnk]

any update on this feature?

[Gujci]

Regarding this feature request, we still have a a metric payload JSON representation in our application. Do you have a best practice to (maybe slice &) send it using the current feature set of Firebase.

[dhritzkiv]

It'd be very useful for the new (in iOS 14) MXBackgroundExitData codes that signify why an app might have been killed in the background. https://developer.apple.com/videos/play/wwdc2020/10078/

[korre]

Any news here?

[elenadoty]

[Cross-posting from a Crashlytics issue]

Hi all,
Crashlytics is looking at incorporating MetricKit into our SDK and would love to get some input. If you're willing, please consider filling out this brief, anonymous survey.

[SwiftNativeDeveloper]

Any updates for 2022?

[jatinmishra]

any updates for 2023, tentative timeline perhaps?

[jesus-mg-ios]

This would be great ...

[Rannie]

Any updates for 2024 :p

[SwiftNativeDeveloper]

It didn't look like Google was going to move on this (or Microsoft for App Center) anytime soon. It is really too bad because the data is so rich and insightful.

I created an extension on Crashlytics and converted MXDiagnosticsPayload data to NSError and record a non-fatal error in a DispatchQueue async. It isn't pretty, and it doesn't retain ANY of the stack frame provided by Apple.

Additionally, I took some key elements from MXMetricPayload, namely the exit data, and did the same, created a non-fatal and/or created events on the analytics API.

We are seeing so much more data come in from MetricKit than Firebase Crashlytics. Even if we could get the MetricKit data denoted as a 'crash' that didn't actually cause a crash, or non-fatal recordError that doesn't capture a stack trace things would be better for my workaround.

[jesus-mg-ios]

@SwiftNativeDeveloper is there any gist where we can find your approach?
Thanks in advance.