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.

Right, I got this to work, but I'm not sure how. Some of the things I did: cleaned up the build folder, deleted all copies of the main application from my hdd, built a new release version of it, put it in Applications, picked that one when Xcode asked me to choose an app to run after building the thumbnail provider extension. That still didn't work, but afterwards I no longer got any store migration errors when building and running in Xcode. So basically the problem seems to have been that Xcode picked an old build of the main application to run with the extension, which created an old version of the Core Data store. Or the old store was still being cached somewhere. Just cleaning the build folder was not enough to fix this.

Thanks for clearing this up! Now let's see if I can make this work.