Sorry for the format. I'll repost the logs here: log stream

I agree that we need to handle scenarios such as force quit or unexpected termination, and we are improving those cases. However, I would still like to clarify the behavior specifically during app updates. on macOS 15 the app terminates cleanly, but on macOS 26 it is immediately killed without entering any shutdown flow. We would like to understand whether this change aligns with the AppleEvent-based quit model you mentioned. Specifically: What is AppleEvent ? Is a quit AppleEvent still sent when TestFlight replaces the app during an update? If so, how can an Electron app observe or respond to it? Has the expected termination behavior changed across recent macOS versions? We also opened an issue on the Electron side for reference: https://github.com/electron/electron/issues/49132 Thank you.

I see, so "quit" AppleEvent is kinda like the Windows WM_QUIT message. In that case Electron should already handle that. We definitely will file a bug. In the meantime, the documentataion for Sudden Termination says it's for shutdown. Does Testflight also use it? If so, what is the default value for NSSupportsSuddenTermination if not set in Info.plist? Should we manually set that value to false in our Info.plist? Even worse, our app is a singleton, which means that when the app relaunches, it fails. This is a bit of bad wording on me. To clarify, it's not the app failing to launch, but that our program expects to launch its child processes then communicate with them using domain sockets, but if leftover orphans from previous sessions were present, then we can't open new domain sockets on the same path because the old one is still there. To be pedantic we could try opening on another path, but we haven't implemented that. Currently if this happens then our program shows error and exit. This is what I mean "fails".

The user can put you into exactly the same state using "Force Quit" as will crashing. The standard solution here is for the child to monitor the parent and self-terminate if the parent dies. We already implemented that. The problem is that, in the case of user force-quitting, the user inflicted that upon themselves so the "the app quit unexpectedly" message is nothing out of ordinary, but if a simple app update also prompts "the app quit unexpectedly" that doesn't sound very good.