firebase-ios-sdk
firebase-ios-sdk copied to clipboard
firebase
[FR] Catching previously uncatchable crashes with MetricKit
Feature proposal
- Firebase Component: Crashlytics
With iOS 14, Apple now has nice support for previously uncatchable crashes like for app hangs, low memory, etc. . Apple makes the raw data, such as the call stack, available to the application, meaning it could just be forwarded to Crashlytics to create a crash report (missing some data fields but still containing the crucial bits, the stack trace and reason for crashing). This could be handled by a generic way of letting a user tell Crashlytics a crash has occurred (https://github.com/firebase/firebase-ios-sdk/issues/5771) or some MetricKit-specific API.
Aside from making this feature request, I'd be curious to hear an estimate on when it would be done (or even prioritized). This would help myself and others weigh if it's worth forking Firebase to implement this ourselves, or if we should wait and see what Firebase releases.
Another thing is, crash reporting of this sort is opt-in, so it'd help to weigh these crashes differently (e.g., since the opt-in rate is anecdotally around 33%, Crashlytics could generate 3 identical crash reports per incident)
Possibly related: https://github.com/firebase/firebase-ios-sdk/issues/3913
Being able to catch hangs and terminations such as low memory would be awesome. Leveraging MetricKit in iOS 14+ seems like a no-brainer for Crashlytics. I also wonder if the Performance module could gain from MetricKit, where additional on-device statistics could be reported automatically.
Hi all, We're looking into potential use cases for this and would love to get some input. If you're willing, please consider filling out this brief, anonymous survey.
Hi all, We're looking into potential use cases for this and would love to get some input. If you're willing, please consider filling out this brief, anonymous survey.
@anisimov-voir @willbattel @exavi @alex-vasenin @fosterbrereton tagging for visibility
Both this thread and #3913 seem to have focused on the MXDiagnosticPayload. Will MXMetricPayload be getting any love too?
@elenadoty I'd be happy to fill out a form on what data points from MXMetricPayload would be of interest to me and my team. --> All of it.
Hi @SwiftNativeDeveloper Currently we've focused on diagnostic payloads since they align more directly with the Crashlytics model (real-time, individual-event level event reports). How would you envision these metric payloads being the most useful in a Crashlytics and/or Fireperf dashboard?
@eacrh I filled out the survey link above in the springtime. Regarding 'event' data, the exit metrics are HUGE. They could be first-party events that get adopted into firebase.
The downside is that exposing these metrics really demonstrates that Firebase doesn't catch nearly as much as Apple provides out of the box with the MXDiagnosticPayloads.
https://developer.apple.com/documentation/metrickit/mxappexitmetric