Seems this broke in Monterey.

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.

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.

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

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.

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.

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

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

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.