Hi! I have a few questions about the lifecycle and capabilities of the Crash Reporter Extension. Besides using the corpsePort to inspect the crashed process through Mach APIs, is it safe/supported/recommended for the extension to access files in a shared App Group container? Are there any caveats or exceptions we should be aware of, for example around memory-mapped files, file coordination, or filesystem access after the host app has crashed? Shall we use some particular APIs for this kind of shared resource or not? While debugging the extension, I noticed that when I trigger a crash in the app I am debugging, LLDB does not stop inside the extension (it also ends up stopping the debugging session). However, I can observe that the extension does run, because it writes data into a shared App Group directory related to the crash. Is this expected behavior? Is there a recommended way to debug the Crash Reporter Extension reliably (with lldb, or other way)? More generally, I would like to better understand the extension lifecycle: When exactly does the extension start running? How long can it live after the app crashes? Is there a time limit for operating on the corpse process? Is the extension subject to resource limits similar to other app extensions, such as memory, disk, CPU, watchdog, or jetsam constraints? If the Crash Reporter Extension itself crashes, how can we detect that? Would those crashes appear in Xcode Organizer, or is there another recommended way to observe them? Any clarification around the supported lifecycle, debugging model, and resource limits would be very useful.

Hi! I have a couple of questions around measuring SDK performance in production, especially battery impact (and related to this, Disk Read/Writes). For an SDK running in the wild, what resources or APIs would you recommend using to evaluate performance impact once the SDK is already deployed to real users? I understand that Instruments and local profiling are the right tools during development, but production introduces a much wider range of devices, OS versions, app behaviors, network conditions, and user patterns (in particular, because SDK goes into different types of apps) In particular, are there recommended ways to understand battery usage attributable to an SDK in production? How can we reason about whether a battery-related issue is actually caused by our SDK rather than by the host app, system behavior, networking conditions, or other third-party SDKs? Any guidance on recommended signals, best practices, or things to avoid when trying to attribute battery impact in production would be very helpful.