MetricKit Metric Payload Split

Thank you for your post. Currently, MetricKit does not provide access to that information. However, the team finds the concept intriguing and would be delighted to receive an enhancement request from you to build that capability.

If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here.

If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

Albert Pascual
  Worldwide Developer Relations.

Glad to hear they're open to new ideas. However, I don't think I was clear about my ask, trying again... :)

I’m trying to understand the scope of an MXMetricPayload versus some of its per-run fields.

Specifically, the payload includes pid and lowPowerModeEnabled. Are these fields guaranteed to describe the same execution whose metrics the payload represents, or can a payload aggregate across multiple launches/time windows?

Concretely:

• If pid == 100, does that imply the payload only covers the run with PID 100?
• If lowPowerModeEnabled can change during a run, is the value in the payload a snapshot (at launch? at collection?) or a derived/aggregated value?
• If a payload can span multiple runs, how are scalar fields like pid and lowPowerModeEnabled determined?

@naftaly I submitted a somewhat relevant feedback a few years ago.

FB9616844 - MetricKit: MXDiagnostic, MXDiagnosticPayload and MXMetricPayload should have 'identifier' properties

I mostly wanted a unique identifier built-in because IPS files have them and then I wouldn't need to decorate the MetricKit payloads myself and it would be just built in.

If you want to correlate runtime data you captured against a payload, your best bet is to do this with diagnostics since those are truly the PID at time of diagnostic--well at least I assume. I've never bothered to check. This could easily be tested by crashing and check the PID in the IPS crash file against that identified in the MXDiagnosticPayload metadata. The metadata is required in the diagnostic payload but it isn't in the metrics payload. While I have not in practice seen the metrics metadata object to be empty in a metric payload, you're right that you can't do much for variation over time. The API just simply doesn't have a way to represent that.

My understanding is that it is the metadata at the time of reporting.

If you're truly interested in the low power mode value over time, I would capture this in your app and then enrich your metric kit payload over time. I think it is unreasonable to expect the system to give you details when your app is background and not executed. You could listen to this while your app is running and record. Exploring creating signpost events would also be an option, though I would do the signpost event, not signpost interval for low power mode changes.

https://developer.apple.com/documentation/foundation/processinfo/islowpowermodeenabled

I have never concerned myself with the PID in the MXMetricPayload's metadata because as you pointed out, it can change over time. What is less likely to change is the TestFlight status. For that, I have done a bit of investigation and I'm waiting on a feedback.

To answer your questions, you can, at the time a metric payload is delivered, check the system properties, PID, thermal state, etc., and just compare.

In the case of TestFlight, the property seems just busted.

FB15701498 - MetricKit / TestFlight: Production Issue - MXMetricManager not generating metric payloads as expected with iOS 18

This is another example where I capture information and enrich the MetricKit payload json when I ship off device. This is another example of 'value at time of payload'. I'm not tracking if the user was installing app store, Xcode, and TestFlight builds throughout a period of time--but my same advice about low power mode above could be taken if I truly was. StoreKit2 has a nice AppStore.Environment property that I switched from reading the sandbox receipt.

You mention you enrich the payloads. Whats your tactic to know you’re enriching it with same run. PID can be reused so that’s a no-go. Timestamps heuristics Can easily be wrong based on a million factors, signposts are flaky at best. How are you sure you’re enriching the right payload?