MetricKit

RSS for tag

Aggregate and analyze per-device reports on power and performance metrics using MetricKit.

MetricKit Documentation

Posts under MetricKit tag

14 Posts
Sort by:
Post not yet marked as solved
1 Replies
308 Views
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
Posted
by edorphy.
Last updated
.
Post not yet marked as solved
3 Replies
834 Views
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.
Posted
by dkvijay.
Last updated
.
Post not yet marked as solved
1 Replies
207 Views
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
Posted
by t3dward.
Last updated
.
Post not yet marked as solved
3 Replies
2.1k Views
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
Posted
by czm.
Last updated
.
Post marked as solved
1 Replies
530 Views
{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?
Posted
by Sodasi.
Last updated
.
Post not yet marked as solved
1 Replies
690 Views
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 } }
Posted
by HelgeBB.
Last updated
.
Post not yet marked as solved
3 Replies
644 Views
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?
Posted Last updated
.
Post not yet marked as solved
1 Replies
521 Views
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!
Posted Last updated
.
Post not yet marked as solved
2 Replies
1.3k Views
Hello guys! I'm trying to collect metrics for each UIViewController in my iOS app. I can see all aggregated metrics except the cumulativeHitchTimeRatio one. I created a sample project and run UI test for more than 2 hours to allow Apple MetricKit to collect the metrics. When I run measure UI test it collects needed data well (look attached screenshots), but, unfortunately, I receive empty signpostMetrics array next day (json attached) in the didReceive(_:) method. Could you help me to understand how to get the cumulativeHitchTimeRatio metric from the MetricKit framework?
Posted
by adnako.
Last updated
.
Post not yet marked as solved
0 Replies
802 Views
Hello all, I wanted to get MXMetricPayload to analyse some App metrics. And for some reason the method func didReceive(_ payloads: [MXMetricPayload]) from mxMetricManager is not being executed. For this I created a Class: import MetricKit public final class MetricKitManagerImpl: NSObject, MetricKitManager { public static let shared: MetricKitManager = MetricKitManagerImpl(mxMetricManager: MXMetricManager.shared) private let mxMetricManager: MXMetricManager private init( mxMetricManager: MXMetricManager ) { self.mxMetricManager = mxMetricManager super.init() mxMetricManager.add(self) } deinit { mxMetricManager.remove(self) } public func didReceive(_ payloads: [MXMetricPayload]) { payloads.forEach { if let scrollHitchTimeRatio = $0.animationMetrics?.scrollHitchTimeRatio.value { sendToSomeWhere(scrollHitchTimeRatio) } } } } Then on the AppDelegate on didFinishLaunchingWithOptions I do: private(set) var metricsManager: MetricKitManager! func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil ) -> Bool { self.metricsManager = MetricKitManagerImpl.shared ... } With this setUp I am able to receive the debug playload (triggered from Xcode Menu. Debug -> Simulate Metrik Kit Payload). However, after using the app for some days, I did not receive any real payload. Did anyone experience this? What am I doing wrong? Thanks a lot in advance! Miguel Franco
Posted Last updated
.
Post not yet marked as solved
0 Replies
760 Views
Hallo all, I did a test integration of MetricKit into one of our apps...I'am on macOS Ventura 13.3.1 (a). The app is not distributed via the App Store. I subscribed to the MXMetricManager and implemented the didReceiveDiagnosticPayloads function. So far everything seems to work, when I use in Xcode: Debug -> Simulate MetricKit Payload I get a callback and the payload. So I did some further testing. When I build the app debug version with a test crash and then run the Debug Version (without Xcode) and let it crash the next time I start the app I get a callback to didReceiveDiagnosticPayloads with all the information about the crash. But I'am not able to get a hang report. I tested it by adding a sleep (60) and adding some intensive computation work on the main thread so that it is busy for several seconds, I get no hang reports :-( I'am using the Debug version and run it without Xcode. Are hang reports expected to be reported immediately? I also get after 24 hours no hang reports. Can someone help me? Thanks and have a nice day!
Posted
by ErichK.
Last updated
.
Post not yet marked as solved
1 Replies
1.1k Views
This is related to my post https://developer.apple.com/forums/thread/724698 where I submitted an issue that MetricKit reports didn't work for System Extensions on mac. I've come to realize that this is also true for Launch Daemons/Agents in the system domain (and so it probably also explains the System Extension case as I understand System Extensions are somewhat like Launch Daemons). I have a "thin executable" (a Command Line Tool target) that registers with MetricKit reports and then just crashes itself. Here's the scenarios I've tested - If I launch this executable as the current user, I receive the crash reports from MetricKit. If I launch this executable as root, I also receive the crash reports. If I register it as a Launch Agent in a "user", or a "gui" domain, I still receive the crash reports. However, if I register it as a Launch Agent in the "system" domain, or as a Launch Daemon, I got this error from the CrashReport process. <<bundle ID>> is not a MetricKit client (I noticed the same error from MetricKit APIs in our system extension targets as well) I decided to open this new post here, because the solution we were talking about in post 724698 - delivering metric reports from system extensions to their host apps - may not apply here, since a Launch Daemon/Agent may not have a host app at all. What is the guidance if we want to receive these reports?
Posted
by qb_s.
Last updated
.