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?

Great stuff. I'm going to give it a go. You're not the first to mention to me that the host app should try and share its port. I'm curious to see how far I'll get. First step is to figure a way to get the underlying xpc_connection_t from an NSXPCConnection. I know there's a private getter, but that'll just get me so far. Thanks again.

To be a bit more clear, I'm doing research on how far I can get today, with the goal of trying to get this to a place where it could be in AppStore distributed apps some day in the future.

Much prefer it to work without developer mode. But I'll take what I can get today, and possible make a feedback request for more.

100%. I specifically only want the extension to have access to it’s host.

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?

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.