App out of memory and killed by Jetsam event seems not report to MetricKit diagnostic, it only contains crash or watch dog kill (scene create or scene update). So I want to ask to report these issues to MetricKit

Hi Apple Developer Community, I'm implementing MetricKit launch performance tracking in our iOS app and need clarification on two properties: histogrammedTimeToFirstDraw histogrammedOptimizedTimeToFirstDraw The Documentation Problem: The official MetricKit documentation provides minimal explanation of these properties beyond their names. Based on naming conventions, I initially assumed: histogrammedTimeToFirstDraw = cold launches histogrammedOptimizedTimeToFirstDraw = warm/optimized launches Based on our measurements: The “optimized” metric appears only in a small fraction of launches The "optimized" metric is actually slower The naming suggests the opposite behavior Questions: What specific launch conditions does each metric measure? Why would "optimized" launches be slower and less frequent? Is histogrammedOptimizedTimeToFirstDraw related to iOS app pre-warming or prediction features? If these metrics don’t correspond to cold vs. warm launch times, is there an alternative way to measure them accurately? Any clarification from Apple or insights from developers who've tracked these metrics would be greatly appreciated.

I'm making a wrapper library to abstract away some of the 'missing platform support' of DeclaredAgeRange until hopefully it expands to additional platforms. When I'm trying to fully enumerate all of the cases of AgeRangeDeclaration, which they all state available starting 26.0 (mysteriously added in Xcode 26.2 beta), the app crashes due to a missing symbol at launch time. This happens both for Xcode 26.1, 26.2 beta 2, and matching Xcode Cloud builds. So I've isolated it beyond "doesn't work on my machine". I just made a handful of crashes and attached a sysdiagnose to a fresh feedback. FB21121092 - DeclaredAgeRange: Eligibility property and new declaration cases unavailable on iOS 26.1 device contradicting documentation - causes runtime symbol not found crash If anyone is curious what these crashes look like I've attached the DiagnosticPayload.jsonRepresentation() generated from one of my favorite frameworks, MetricKit. Very clearly articulated in the diagnostic metadata you can see the symbol not found. "diagnosticMetaData" : { "platformArchitecture" : "arm64e", "terminationReason" : "Symbol not found: _$s16DeclaredAgeRange0bC7ServiceV0bC11DeclarationO14paymentCheckedyA2EmFWC\nReferenced from: <1894EDCB-3263-3604-8938-97D465FF3720> \/Volumes\/VOLUME\/*\/PerformanceOrganizer.app\/PerformanceOrganizer\nExpected in: <B8FD2C23-0CC9-3D94-902D-875900307A7A> \/System\/Library\/Frameworks\/DeclaredAgeRange.framework\/DeclaredAgeRange", "exceptionType" : 10, "appBuildVersion" : "745", "isTestFlightApp" : true, "osVersion" : "iPhone OS 26.1 (23B85)", "bundleIdentifier" : "dev.twincitiesapp.performanceorganizer", "deviceType" : "iPhone18,1", "exceptionCode" : 0, "signal" : 6, "regionFormat" : "US", "appVersion" : "2.0.0", "pid" : 22987, "lowPowerModeEnabled" : false } DiagnosticPayload.json This is the offending code in a type I control and make available on other platforms but leave unused. extension AgeRangeDeclaration { // A factory or initializer that takes the AgeRangeService.AgeRangeDeclaration and maps to the common AgeRangeDeclaration type public init?(platform value: AgeRangeService.AgeRangeDeclaration?) { guard let value else { return nil } switch value { // Xcode 26.1 visible cases case .selfDeclared: self = .selfDeclared case .guardianDeclared: self = .guardianDeclared // Xcode 26.2 visible cases // This is the first culprit, all of the following symbols would crash, this is just the first case .checkedByOtherMethod: self = .checkedByOtherMethod case .guardianCheckedByOtherMethod: self = .guardianCheckedByOtherMethod case .governmentIDChecked: self = .governmentIDChecked case .guardianGovernmentIDChecked: self = .guardianGovernmentIDChecked case .paymentChecked: self = .paymentChecked case .guardianPaymentChecked: self = .guardianPaymentChecked @unknown default: // Apple added new cases in Xcode 26.2 betas that were available in iOS 26.0, // so it is probable that this could happen again. If it does, assert to let developers // bring it to my attention. assertionFailure("Invalid or out of date knowledge of age range declaration \(value)") self = .unknown } } } For what it is worth, the same is also true for isEligibleForAgeFeatures which I suspect was also added to Xcode 26.2 somehow but not made available to real devices running [26.0 - 26.2). As a side note, thank you for this property, it will let me check what states I need to perform extra checks for in a clean way, I just will need it to now not crash my app on 26.0 and 26.1 runtime devices. :) Edit: DTS did confirm on a comment I had in another thread that this is a bug. Now just to wait for an Xcode beta update. https://developer.apple.com/forums/thread/807906?answerId=867205022#867205022 In any case, this is a great example of how MetricKit totally rocks capturing things other off the shelf crash tools might not have a chance to get. I did have to roll back my TestFlight to an earlier build, but MetricKit was there to send me the previous crashes as soon as the app could launch. Thanks MetricKit team!

I use CI/CD dsym, downloaded into local directories, but there seems no direct way using it in Xcode

The MXCrashDiagnostic and MXHangDiagnostic reports are not being returned via MXMetricManager on the next app launch in iOS 17.2, 17.3, 17.4, and 17.5. This issue prevents collection of crash and hang diagnostics through the MetricKit framework, which worked as expected on earlier and later (18, 26) iOS versions. Steps to Reproduce:- Integrate MetricKit in an iOS app using: MXMetricManager.shared.add(self) and implement: func didReceive(_ payloads: [MXDiagnosticPayload]) Install and run the app on a device running iOS 17.2 or later. Cause a crash or hang scenario (e.g., dereference a null pointer or block the main thread). Relaunch the app after the system terminates it. Observe the callback for diagnostic payloads. Expected Behavior MXMetricManager.shared.didReceive(_:) should be invoked on the next launch, returning diagnostic payloads that include MXCrashDiagnostic or MXHangDiagnostic objects. Actual Behavior: No diagnostics are returned on subsequent launches. didReceive(_:) is not triggered, or the diagnostic payloads array is empty. This behavior is reproducible across multiple devices and iOS versions (17.2–17.5). iOS Versions: 17.2, 17.3, 17.4, 17.5 Devices Tested: iPhone 14, iPhone 15 Pro Xcode Version: 15.2 / 15.3 Framework: MetricKit Diagnostic Type: Crash and Hang

I'm adding a few custom signposts with mxSignpost(.begin,...) and mxSignpost(.end,...). Is there a way to force delivery of the MXMetricPayload so I don't need to wait for the daily aggregation to be pushed?

In MetricKit, a metric payload comes in with a time range which usually means it contains multiple launches/sessions. How can we relate things that will change between launches or sessions such as pid and lowPowerModeEnabled from the metadata. Will there be multiple payloads for each unique value or is there some other way to use this?

Can you confirm that if you launch an app in the U.S. (in the iOS store) that is you cannot select a specific state (i.e. Rhode Island, North Carolina etc.) to roll out your app? In other words when you launch your app in the U.S. it has to be for the entire country right? Can someone please confirm that this is the case and has always been the case in any app store (i.e. Google Play and IOS)? Thanks. - Erik

In recent versions, the increase in background abnormal exits is significant. According to monitoring data, it is closely related to the iOS 26 system. Could you please look into the reasons or provide some suggestions for troubleshooting the issue?

I'm working on adding MetricKit to our iPad application that we distribute internally via Enterprise distribution. I've set up the didReceive functions for both MXMetricPayload and MXDiagnosticPayload. When I build onto a device via Xcode and use the Simulate MetricKit Payloads command, everything works as expected. The issue I'm having is when testing on a device via our enterprise distribution. When I simulate a crash, I am receiving the MXDiagnosticPayload so that part is working correctly. However, I am never receiving a MXMetricPayload. I've been using the app and waiting up to 3 days in some tests and not receiving any payload over that time frame. Some information I found suggested the issue might be MetricKit not working fully on enterprise apps but I haven't been able to find a definitive source on that question. Hoping someone here can guide me on that. Thanks!

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!

Background: During daily usage of iOS devices, devices experience noticeable thermal issues. This heating not only affects user experience, but may also lead to device performance throttling, shortened battery life, and other problems. We need better understanding and monitoring of device thermal states to optimize application performance and user experience. Issues Encountered: Insufficient thermal monitoring capabilities: Unable to obtain real-time accurate temperature data from devices Difficult power consumption analysis: Hard to determine which specific modules or threads cause high power consumption and heating Requested Solutions: Temperature Monitoring API: Provide accessible device temperature reading interfaces Thermal Attribution Analysis Capability: During heating events, we expect to receive more detailed power consumption monitoring data, such as CPU, GPU, network, location services, display, high power consumption thread stacks and other information to help developers identify high energy consumption operations

Two month back we published 28.11.0 version a app. for both foreground and background terminations are not properly showing by Xcode matrix Foreground Termination: I was able to see the termination bar chart for one release, but after that, the chart stopped showing real-time crash progress. However, crashes are still being reported directly by users. Why is Xcode Organizer unable to capture these events? Please help us track them effectively. Background Termination: The termination bar chart has not appeared in Xcode Organizer for the last two releases, which span nearly two months. As a result, we are unable to monitor app terminations for background scenarios.

Hello, I am currently developing an iOS SDK, and I would like to clarify the allowed use of MetricKit, specifically regarding the MXAppRunTimeMetric.cumulativeBackgroundTime value. My SDK tracks app lifecycle events for analysis purposes. I am considering sending the cumulativeBackgroundTime metric to my own backend server to monitor background usage patterns across different devices. Before proceeding, I want to confirm: Is it compliant with Apple’s App Store Review Guidelines to collect cumulativeBackgroundTime via MetricKit and transmit that data to my server? I understand MetricKit is primarily intended for performance monitoring and local analysis, but since this is a runtime metric, I would like to verify whether off-device aggregation is acceptable. I would appreciate any clarification regarding policy boundaries or best practices for this scenario. Thank you in advance!

What are my options if I want to iterate over loaded images (dynamic libraries) within a signal handler? I have a few solutions that might work, but without going too much into them, i'm curious if anyone has experience here, or ideas what to look into. Cheers, AC

what is that makes the TLS be the TLS/SErver ?

Hello Apple, I am trying to get information such as crash context whenever a user encounters a situation where the app is killed. I was wondering if the tool MetricKit is available to all users or is this a feature to those who has opted into it. I am aware that the whenever someone gets a new device or in settings, an option will appear that'll have users decide whether or not to have Apple receive data analytics during certain events on their device. Does this have any effect on whether some users may not have MetricKit? Overall, we are attempting to use MetricKit to better analyze performance of our app. It would be inefficient for us, if the population of users using MetricKit is only those who have opted into it. Thanks, dmaliro

why my Xcode organizer can not show Hangs

We are looking for a platform or portal provided by Apple that allows us to track crashes, hangs, or other runtime issues faced by users while using our iOS/macOS application. This is similar to how we currently use Windows Error Reporting (WER) for our Windows application. Important note: Our application is not distributed via the Apple App Store — it is delivered through enterprise distribution or ad-hoc provisioning.

We are currently pulling data via the API to look various metrics, including reviews and ratings. However, I noticed the ratings only come in with associated reviews - it doesn't appear there is public access to the API for pulling all historic ratings (without associated reviews). Is this correct? Does anyone know a workaround or way to access the ratings data via API or other method?