This happens with my own code as well as with the Apple example code here: Supporting Drag and Drop Through File Promises When dragging a file promise, the above example code will fail if the destination is in /tmp. It will print out the following message to the console: An error occurred while attempting to get a unique promise file URL. Error: Did not receive a valid URL. It doesn't seem to fail if you create a directory inside /tmp and drop into that. But dropping in /tmp fails 100% of the time. And it fails for MacOS Versions from Sequoia all the way up to the most recent Golden Gate beta. Using /tmp as a destination should most certainly be allowed, but if for some reason it isn't, is there any way in my own code to detect the drop destination and perhaps warn the user that they need to drop somewhere else? To reproduce this error, use the following steps: Download the Apple example code from the link above Open the project in Xcode, build it, and run it Drag any image into the example app's main window Open a Finder window and navigate to /tmp Drag the image from the example app into the /tmp directory in the Finder window. You will see the above error in the Xcode console and the drop will fail.

I'm trying to rewrite an old AppleScript mail rule that I used extensively as a Mail extension using the MailKit framework and I've run into an issue. Previously, when developing the script, it was possible to debug it by selecting the message I wanted it applied to and choosing the Mail.app menu item "Message/Apply Rules" This would re-execute my script and I could iterate over it as many times as I liked while developing. I haven't found any great way of doing this for my extension with a MEMessageActionHandler. The closest I've found is to forward the message to myself and wait for it to come back in again over the internet, at which point the extension would get executed again. Needless to say, this makes debugging my MEMessageAction handler much slower. I've tried a number of things in Mail.app to try and get it to re-execute my extension with a particular message without any luck. Does anyone know of a good process for debugging a MEMessageActionHandler that doesn't involve forwarding the message to myself over and over and waiting for it to come in each time?

This issue has already been reported to Apple via the Feedback Assistant as FB12401598 and a code-level support incident has been opened to follow up, but so far I haven't heard anything. The problem is that the NSAttributedString used to be able to load HTML files correctly via the [NSAttributedString initWithHTML:options:documentAttributes:] method (or its Swift equivalent). As of the developer beta of Sonoma, however, this no longer works. The method loads the attributedString but HTML tables are completely ignored. Every cell in the table just appears on a new line. The app I'm working on has a bunch of HTML templates that get drawn inside another View using an NSAttributedString. This has worked for years but no longer works on Sonoma. Does anyone know a decent workaround for correctly drawing some formatted text whose formatting is specified via HTML? I'm currently exploring the idea of converting the HTML files to RTF on an older system and using RTF, but the RTF format isn't nearly as simple as HTML. Here's a screenshot of a simple project and Safari showing the same HTML side by side