After seeing the public tweet about this issue I dug into it myself out of curiosity and because I was concerned my own receipt validation might be vulnerable to the problem. In my analysis I did find some dates that are now including milliseconds, but only in and undocumented field for the receipt file. If @depth42 is using the receipt file data for the "original purchase date" (not receipt download date), then that might explain it. Unfortunately this has never been exposed publicly through the receipt file format, though it is publicly exposed through the server-side receipt validation API.

@Etresoft are you sure you're not thinking of the web API response? The local receipt file does not have any documented field for the original purchase date of the app.

BAL: ***** KON: Yeah.

I suspect NSAlert is not expecting there to ever be more than 3 buttons. It looks like NSAlert does a lot of "just in time" relayout that includes bundling all the buttons/etc up in container views depending on the style of the alert. One of the internal methods -[NSAlert buildAlertStyle:title:formattedMessage:first:second:third:oldStyle:] sort of hints at this limitation.  The documentation for addButtonWithTitle: does suggest it supports more than three buttons, so I would say this is a bug. I suspect the container view holding the buttons is not being allowed to grow tall enough to contain them with the required padding.

I was wrong about the assumption that the container view is not being grown tall enough to give the buttons room. The problem is more insidious than that. Here I've arranged for the button container (a stack view) to be tall enough to show all the buttons and then some. You can see from the View Debugger screenshot that the actual visual glitch is rooted in the secondary buttons not having the "button bezel view" that the first button has. I've confrmed the bezel view is there but is set to hidden. The button and cell in this case are customized by NSAlert and are of class _NSAlertButton and _NSAlertButtonCell. So something is causing it to intentionally hide the bezel for these buttons but I agree it doesn't look good!

I came up with a workaround that seems to achieve the desired outcome. In addition to the buttons not drawing their backgrounds, there's a problematic line that appears after the 2nd button, presumably to set it apart from the cancel button. As a quick fix I just hide it, along with undoing the "draws only while mouse inside" setting that the frameworks have set: class HackAlert: NSAlert { @objc override func layout() { super.layout() for button in self.buttons { button.showsBorderOnlyWhileMouseInside = false } if let containerView = self.buttons.first?.superview { let boxes = containerView.subviews.compactMap { $0 as? NSBox } boxes.forEach { $0.isHidden = true } } } } Putting aside the question of whether it's right or wrong to work around this glitch, I do think this looks better, and it seems like a pretty safe way to achieve the desired outcome. It's important to make the tweaks in a subclass override of layout because that is where NSAlert seems to do all of its customizing of the UI before presentation.

I ended up writing a blog post to document this a bit more cohesively: https://indiestack.com/2022/02/hacking-nsalert-button-appearance/

I was frustrated by this today and decided to dig into it. tldr: pass "-cv_note 0" to quiet just these messages and not all system logs. You can read more about my analysis here: https://indiestack.com/2022/03/quieting-cvdisplaylink-logging/

I was frustrated by this today and decided to dig into it. tldr: pass "-cv_note 0" to quiet just these messages and not all system logs. You can read more about my analysis here: https://indiestack.com/2022/03/quieting-cvdisplaylink-logging/

I was frustrated by this today and decided to dig into it. tldr: pass "-cv_note 0" to quiet just these messages and not all system logs. You can read more about my analysis here: https://indiestack.com/2022/03/quieting-cvdisplaylink-logging/

Oh, thanks Quinn! I missed this reply until now in the hubbub of WWDC week. Yes, when the app crashes it is apparently always "lurking in the background," so it matches up with the profile of what TAL is purported to do. However, the app hasn't opted in to sudden termination, and reports of the problem suggest the app's icon does disappear from the Dock when the issue occurs. It's also affecting a couple other apps on one of the users' systems, but always the same few apps! Any other inspirations about things I can ask the person who reproduces it regularly to try? Or things to look for in the log about reasons it might be terminated? Thanks so much! Daniel

I see now that there is a distinction between "automatic" and "sudden" termination, and I think the "automatic" termination is the one that correlates with TAL. I'll take a closer look at these keys, maybe even if I don't specify support for either one I can enable them to get a better feeling for whether the behavior I then see matches what other users are seeing.

I think I might have a breakthrough. Scanning the sysdiagnose from my friend's Mac I came across this line in launchd.log, which I think correlates with one of the unexpected terminations: 2022-05-03 09:15:22.088718 (gui/501/application.com.red-sweater.marsedit4.384452971.384452977 [13840]) : exited with exit reason (namespace: 15 code: 0xbaddd15c) - OS_REASON_RUNNINGBOARD | <RBSTerminateContext| code:0xBADDD15C explanation:CacheDeleteAppContainerCaches requesting termination assertion for com.red-sweater.marsedit4 reportType:None maxTerminationResistance:NonInteractive attrs:[ When I search my own Mac's launchd logs for RBSTerminateContext, I only find it a few times relating to the Apple News app and some message about Catalyst apps not being permitted to "task-suspend."

Sorry for the blast of follow-up messages, but now with the clue of "RunningBoard" I came across this article, https://eclecticlight.co/2019/11/07/runningboard-a-new-subsystem-in-catalina-to-detect-errors/, which includes an eyebrow-raising sentence: Catalina brings several new internal features, a few of which have been documented, but others seem to have slipped past silently. Among the latter is an active subsystem to replace an old service assertiond, which can cause apps to unexpectedly terminate – to you and me, crash – in both macOS 10.15 and iOS 13: RunningBoard. Given the seemingly pertinent RunningBoard termination in the log, and the allusion to "unexpected termination" by the article cited, I think I am on to something here!

I managed to trace this down to the system frameworks level inside the private DeleteCache.framework. It seems that this framework runs a daemon, "deleted" which is responsible for handling requests to free up purgeable space. This is likely to happen when the system notices there isn't much disk space left, or when a 3rd party utility such as CleanMyMac specifically requests (I think via SPI) that the space be purged. I guess the system considers this enough of an emergency tactic that it doesn't hesitate to proactively terminate the corresponding apps to which the purged caches belong. Thanks for inspiring me to look into this more deeply, Quinn. I think I'm all set now and hopefully this thread will serve as a reference for others who might run across the mysterious quitting behavior.