It seems this can happen if an alert is opened as a result of a menu selection, or if a new alert is opened immediately after closing an old one, and it seems to go away if I add a half-second delay before opening the new alert. I might make a bug report later.

Additional info: I noticed that whenever this happens, there are two AXUIElementDestroyed notifications posted.

Thanks! I've also noted that the alert only seems to appear when writing to a file using the NSData writeToURL:options:error: method with the NSDataWritingAtomic option. Not with options: set to 0. Not when writing to the same "illegal" directory with the NSFileWrapper writeToURL:options:originalContentsURL:error: method or NString writeToURL:atomically:encoding:error:.

Basically, it is caused by the fact that NSView clipToBounds is set to NO by default in Sonoma, but in Debug View Hierarchy it is still drawn as if clipToBounds were set to YES. This is obviously an Xcode bug.

Seems that the image view at the top is for some reason drawn over the textview at the bottom. If I remove the image view, the text view is visible again.

Right, I think I managed to file a bug report, with number FB11990678. https://feedbackassistant.apple.com/feedback/11990678

Nope, everything is built from within Xcode. As I wrote, is seems to be the fact that the dynamic library targets had no entitlements files that confused the "sign for App Store" stage somehow, as simply adding those files fixed everything. If you are really interested, the full project is available here: https://github.com/angstsmurf/spatterlight/tree/appstore . Going back to the commit before the last should make the problems reappear. Note that only the appstore branch is signed and has everything properly set up for the App Store.

This was solved in a reply on Stackoverflow (https://stackoverflow.com/questions/75422505/how-to-prevent-xcode-from-adding-malformed-entitlements-to-my-dylibs/75422519#75422519), which seems to be written by ChatGPT of all things. The problems seems to have been that my dylibs didn't have any .entitlements files. I created new ones, and in the review shown by Xcode before submitting the app, it seems as if the entitlements in them were stripped, which makes sense if dylibs are not supposed to have entitlements. What makes less sense is that they need entitlements files.

Seems this broke in Monterey.

I got this reply - https://stackoverflow.com/questions/67386175/nstextview-always-uses-system-language-when-hyphenating?noredirect=1#comment119156272_67386175 on StackOverflow: NSAttributedString reads the language from NSUserDefaults with key NSHyphenationLanguage. This is undocumented and may not work in every version of macOS. I guess that is as close to a fix for this as I am going to get.

It was pointed out to me that the documentation for hyphenationFactor states "This property detects the user-selected language by examining the first item in preferredLanguages." So I guess there is no way to change this undesirable behaviour.

This seems to be a Catalina only bug (earlier versions do not support this kind of Quicklook extension.) Upgrading to Big Sur made it go away.

EDIT: Made a video to illustrate this problem: youtu.be/l7b1jq7pDWY Original code is here: https://github.com/angstsmurf/spatterlight/blob/quicklook-ifiction/iFictionQuickLook/iFictionPreviewController.m

It is a standard Mac app. I finally got it to build again, after removing the App Groups entitlement from all the targets. Now I'll try again to see if I can understand what you're saying in the other post. EDIT: Yeah, I had missed the team identifier prefix. Now it works. Thanks! Of course, it still won't build "out of the box", and building it will be non-trivial for anyone without a paid developer account. But I think we can mark the question I ask in the subject line as solved.

Nope, this stuff is apparently way over my skill level. Xcode refuses to build my project without a provisioning profile.