Thanks for the response. I've read your post many times over, it's the reference, and it's a great one. That being said, obviously your stance is the right one, but as you sort of mention, some of us don't have a choice of writing a crash reporter because the one supplied to us by the OS is too limited or just doesn't cover everything we need. That being said, I'm curious what you think about using task_info and TASK_DYLD_INFO, and caching that address. That is not signal safe, but after that we're talking lockless access to a mutable list that will only ever grow which is way better than wasting resources caching dyld updates, and is signal safe.

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?