I have integrated MetricKit into my production app and listening for the corresponding callback func didReceive(_ payloads: [MXDiagnosticPayload]) After some time, I've noticed that the hang diagnostics data collected are all for hangs longer than 1 second. Does MetricKit only collect hang data for hangs longer than 1 second? Can this threshold be adjusted, for example, to 500ms? Is there any sampling involved in the collection of hang diagnostics? The number of hang events collected by MetricKit is significantly lower compared to other third-party platforms. Thank you for your response, this is very important to me.

No metrics data found for the latest app versions with sufficient usage. What is sufficient usage ? Can we define sufficient usage ourself ? if Yes then how ? https://developer.apple.com/videos/play/wwdc2020/10076/ wwwdc200 does mention factor of 5, but 5 of what ? and when where is the definition ? Organizer -> Metrics is useless if there is no data. If someone knows the fix please suggest.

In statistical objects In MXMetricPayload histogrammedTimeToFirstDrawKey start times not equal applicationExitMetrics exit： case1: "applicationExitMetrics": { "backgroundExitData": { "cumulativeNormalAppExitCount": 3, "cumulativeMemoryPressureExitCount": 4 }, "foregroundExitData": { "cumulativeMemoryResourceLimitExitCount": 3 } }, "applicationLaunchMetrics": { "histogrammedTimeToFirstDrawKey": { "histogramNumBuckets": 14, "histogramValue": { "10": { "bucketCount": 1, "bucketStart": "1740 ms", "bucketEnd": "1749 ms" }, "2": { "bucketCount": 1, "bucketStart": "1440 ms", "bucketEnd": "1449 ms" }, "3": { "bucketCount": 2, "bucketStart": "1490 ms", "bucketEnd": "1499 ms" }, "11": { "bucketCount": 1, "bucketStart": "1780 ms", "bucketEnd": "1789 ms" }, "4": { "bucketCount": 1, "bucketStart": "1500 ms", "bucketEnd": "1509 ms" }, "5": { "bucketCount": 1, "bucketStart": "1580 ms", "bucketEnd": "1589 ms" }, "12": { "bucketCount": 1, "bucketStart": "1860 ms", "bucketEnd": "1869 ms" }, "6": { "bucketCount": 1, "bucketStart": "1620 ms", "bucketEnd": "1629 ms" }, "13": { "bucketCount": 1, "bucketStart": "1990 ms", "bucketEnd": "1999 ms" }, "7": { "bucketCount": 1, "bucketStart": "1650 ms", "bucketEnd": "1659 ms" }, "0": { "bucketCount": 1, "bucketStart": "1400 ms", "bucketEnd": "1409 ms" }, "8": { "bucketCount": 1, "bucketStart": "1660 ms", "bucketEnd": "1669 ms" }, "1": { "bucketCount": 1, "bucketStart": "1430 ms", "bucketEnd": "1439 ms" }, "9": { "bucketCount": 1, "bucketStart": "1730 ms", "bucketEnd": "1739 ms" } } }, In this Case the app cold started 15 times, but quit only 10 times， why？？ case2: "applicationExitMetrics": { "backgroundExitData": { "cumulativeMemoryPressureExitCount": 1 }, "foregroundExitData": { "cumulativeMemoryResourceLimitExitCount": 3, "cumulativeNormalAppExitCount": 1 } }, "applicationLaunchMetrics": { "histogrammedTimeToFirstDrawKey": { "histogramNumBuckets": 3, "histogramValue": { "0": { "bucketCount": 1, "bucketStart": "1490 ms", "bucketEnd": "1499 ms" }, "1": { "bucketCount": 1, "bucketStart": "1680 ms", "bucketEnd": "1689 ms" }, "2": { "bucketCount": 1, "bucketStart": "1880 ms", "bucketEnd": "1889 ms" } } }, The app cold started 3 times, but quit unexpectedly reached 5 times， why？？？

I've recently started working with IPS files, specifically crash reports. According to the documentation there are a number of metadata keys included in these payloads, however, I have found a number that are present in real ips files from device but are not documented. Does anyone know what version of iOS these 'new' metadata keys were introduced? How about if they're expected or if I should treat them as optional. https://developer.apple.com/documentation/xcode/interpreting-the-json-format-of-a-crash-report#IPS-metadata { "app_name":"ApplicationNameHere", "timestamp":"2024-02-15 08:05:05.00 -0600", "app_version":"1.6.0", "slice_uuid":"6b1f9f4e-3025-364f-9847-914fc1fe14d1", "build_version":"800", "platform":2, "bundleID":"reverse.domainname.bundleidentifier", "share_with_app_devs":1, "is_first_party":0, "bug_type":"309", "os_version":"iPhone OS 17.3.1 (21D61)", "roots_installed":0, "name":"ApplicationNameHere", "incident_id":"1CF0B8A1-EB43-46B3-AA9F-CFA8A9259190" } The following keys are not in the documentation: app_name, os_version, slice_uuid, share_with_app_devs, is_first_party, roots_installed I created this feedback to request the documentation be updated with current state. FB13631161 - Developer Documentation: Update IPS metadata to reflect latest values found in IPS Metadata JSON

Hello, I am looking for a guide on what the HUD graph axis' are, with my main curiosity around the GPU metering. Is this number the load average of the cores, similar to the load avg you see in uptime/top or is it another descriptor? I've not been able to refer to a man page or the readme for this, google searches have yielded me many ways to disable the HUD, but no guide

{signal=SIGKILL, exceptionCode=0x00000000, virtualMemoryRegionInfo=unkown, terminationReason=<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[application<com.***.***>:3682] failed to terminate gracefully after 5.0s ProcessVisibility: Background ProcessState: Running WatchdogEvent: process-exit WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 12.680 (user 7.120, system 5.560), 41% CPU", "Elapsed application CPU time (seconds): 1.309, 4% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive>} i have no idea about this crash. who can explain this for me? what cause this problem? when does this problem occur?

Hi folks! My iOS app has the MetricKit integration, and I'm processing the reports on my server. While looking at some MXCrashDiagnostic reports, I saw certain reports that has threadAttributed property as true, but callStackRootFrames is just an empty array. So the report looks like the following example "callStacks" : [ { "threadAttributed" : true, "callStackRootFrames" : [ ] }, // ... // other callstacks where threadAttributed is false // but callStackRootFrames is not empty ] Looking at the documentation I can see threadAttributed is used to determine if the crash/exception occurred in this crash. So I can't understand how callStackRootFrames can be empty when threadAttributed is true. Is this a bug or an expected behavior? Also, is there a case where the crash/exception report does not have any callstack with threadAttributed as true? From the definition, it feels like there should always be exactly one attributed thread on each crash report. Thanks for the help!

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?

The MetricKit implementation is pretty straight forward. I am testing it now for a couple of days, but I never saw any report passed to my test apps. (implemented it in an empty app that just crashes every now and then and in a product of ours) The function 'didReceive' is never called and each time I am asking 'MXMetricManager.shared.pastDiagnosticPayloads' I get an empty collection. So that is the secret here? Is MetricKit not working for development builds? Or are there other factors/requirements not meet? import Foundation import MetricKit class CrashDetection: NSObject, MXMetricManagerSubscriber { @objc static let shared = CrashDetection() @objc private override init() { } internal static var crashDidOccur: Bool { get { UserDefaults.standard.bool(forKey: crashDidOccurKey) ?? false } set { UserDefaults.standard.set(newValue, forKey: crashDidOccurKey) } } @objc func start() { MXMetricManager.shared.add(self) } @objc func stop() { MXMetricManager.shared.remove(self) } func didReceive(_ payloads: [MXDiagnosticPayload]) { let crashDiagnostics = payloads.compactMap({ $0.crashDiagnostics }) CrashDetection.crashDidOccur = crashDiagnostics.isEmpty == false } }

The crash data opt in rate is 36% for my app. I have another crash reporting framework PLC in the app. The total number of crashes reported by MetricKit health report was 43% of the total crash count from PLC in May. This almost matched the 36% opt in rate. In the month of June we fixed a series of crashes. Now the total number of crashes reported by MetricKit health report is 80% of the total crash count from PLC. The crash data opt in rate has stayed at 36% for the past 90 days and I am not able to understand how the ratio flipped from 43% to 80%. Looking for guidance here.

I am trying to implement MetricKit so later I could analyze MXCrashDiagnostic and MXHangDiagnostic reports. However when I am triggering a test crash, Here is an example of what I get for MXCrashDiagnostic: iente "timeStampEnd": "2021-06-07 15:59:00 +0000", "crashDiagnostics": [ { "version": "1.0.0", "callStackTree": { "callStacks": [ { "threadAttributed": true, "callStackRootFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "35463E49-9534-3644-B993-2A73C287A143", "offsetIntoBinaryTextSegment": 4329963520, "sampleCount": 1, "binaryName": "demo", "address": 4333717704 }] I tried to symbolicate the the data, by executing commands: atos -arch arm64e -o /Users/***/Downloads/!dsym-4/demo.app.dSYM/Contents/Resources/DWARF/demo 4333717704 But I can't find the crash stack and the result returned is 4333717704 the DSYM file uuid is UUID: 35463E49-9534-3644-B993-2A73C287A143 (arm64) /Users/***/Downloads/!dsym-3/demo.app.dSYM/Contents/Resources/DWARF/demo How should the stack returned by MetrickIt be symbolized? Who can tell me very grateful