Hi Apple Engineering, Following up on FB21418571 filed 2 weeks ago. This is a critical regression in macOS 26 affecting all Electron-based App Store apps. The appstoreagent now uses RBSTerminateRequest instead of the AppleEvent quit mechanism used in macOS 15. When RBS fails (due to termination resistance mismatch), SIGKILL is sent instead of falling back to AppleEvent, preventing graceful shutdown. Impact: Orphaned child processes after TestFlight updates App cannot relaunch (domain sockets still occupied) Affects all apps using IPC via domain sockets Could you please provide an update on the investigation status? Thank you.

We've done further investigation and found the root cause. The Difference: AppleEvent vs RunningBoard We captured logs on both macOS 15 Sequoia and macOS 26 Tahoe during TestFlight updates: macOS 15 Sequoia (works correctly): [appstoreagent] Activating app and telling it to quit: com.synology.deepsearch [App] RECEIVED:(aevt,quit) {aevt,quit...} [App] Handling Quit AppleEvent [App] applicationShouldTerminate: called [App] terminate: called ... graceful shutdown ... [appstoreagent] App detected as terminated after waiting macOS 26 Tahoe (broken): [appstoreagent] Sending terminate request: <RBSTerminateRequest| predicate:<RBSProcessBundleIdentifierPredicate "com.synology.deepsearch"> maxTerminationResistance:NonInteractive> [appstoreagent] Received terminate request response: <Error Domain=RBSRequestErrorDomain Code=4 "Target process has a higher termination resistance than the termination context"> [appstoreagent] Received terminate request response: <Error Domain=RBSRequestErrorDomain Code=3 "No such process found"> Conclusion: On macOS 26, TestFlight/appstoreagent uses RunningBoard (RBSTerminateRequest) instead of sending an AppleEvent quit. The RBS request fails because the app has higher termination resistance than NonInteractive, and then the app is simply killed (SIGKILL) without any fallback to AppleEvent. No applicationShouldTerminate:, terminate:, or any shutdown callbacks are invoked. The app has zero opportunity to clean up. This appears to be a regression in how appstoreagent handles app termination on macOS 26. Filed: FB21418571

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.

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".

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.

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