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 ended up writing a blog post to document this a bit more cohesively: https://indiestack.com/2022/02/hacking-nsalert-button-appearance/

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

BAL: ***** KON: Yeah.

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

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.