Hello,
For the past few days I have been working on integrating a Crash Reporter called "BugSplat" to our macOS desktop app and it got me thinking, how do crash reporters work on macOS ?
After days of trial and error (and claude's help) I managed to integrate it but with a different behavior than windows.
On Windows: When the app crashes, the BugSplat crash report window opens and allows you to write your details and message to be sent with the crash report (along with a log file)
On macOS: It displays the normal macOS' "App exit unexpectedly", to which I click dismiss. But then when I re-open the app the BugSplat crash report window appears.
I asked claude if I can avoid the normal macOS dialog entirely, to which it replied: "This is by design — BugSplat macOS is a next-launch crash reporter, not an in-process one. Here's why that's intentional and unavoidable:
When a process crashes (SIGSEGV, SIGBUS, etc.), macOS's ReportCrash daemon independently monitors all processes and shows the "quit unexpectedly" dialog — there's no API to suppress it. Meanwhile, BugSplat's Mach exception handler captures the crash data to disk. On the next launch, BugSplat finds that crash data and shows its dialog.
This is the same model used by every macOS crash reporter (PLCrashReporter, Firebase Crashlytics on macOS, etc.). The process heap is in a corrupted state at crash time, so showing UI from inside the crashed process is unreliable."
LLMs sometimes speak confidently even when they're wrong so that's why I'm asking: Is it really true that that's the normal behavior for every crash reporter? And is it really that huge of a change to overwrite the macOS dialog entirely ?
Thank you in advance and sorry for the long paragraph
how do crash reporters work on macOS ?
They don’t )-: Well, not in all circumstances |-: I have a long and involved explanation of crash reporting techniques in Implementing Your Own Crash Reporter.
On macOS you have more flexibility than you do on iOS, in that you can do crash reporting both in and out of process. Sadly, neither is a good option:
- With in-process crash reporting your crash reporter can fail due to the process’s state being corrupted, which is the sort of thing that triggered a crash in the first place.
- When working out-of-process it’s hard for the crash report to get access to the information it needs in a supported way, that is, something that’ll work in the long term.
Regarding your specific issue:
[can I] avoid the normal macOS dialog entirely
Not in any supported fashion. The issue here is that the exact hook used by the Apple crash reporter is not considered API. It has changed over the years and it’s easy to imagine it changing in the future. So, while it is possible to suppress the Apple crash reporter on any given releases of macOS [1], there’s no guarantee that’ll continue working in the long term. Which is fine for the Apple crash reporter, because Apple can update it as the system evolves, but problematic for a crash reporter that’s baked into your app.
Oh, and suppressing that alert while allowing the Apple crash reporter to run is not at all feasible. Which is problematic because you really want to allow the Apple crash reporter to run. See Preserve the Apple Crash Report in Implementing Your Own Crash Reporter.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Or at least it was possible the last time I tried this myself. Things might be different on modern versions of macOS because we keep tightening up this path for security reasons. And that’s really the point I’m trying to get at here.