[quote='849011022, DTS Engineer, /thread/792033?answerId=849011022#849011022'] By design, the FileManager won't remove objects marked immutable, which would also prevent directory removal. [/quote] Good guess, but that wasn't the issue, even though it would have made a lot of sense. It's unfortunate I left that part of the code in there, but the user actually tested my App Store app with and without unlocking locked files (the app contains a switch for that), which didn't help, and they sent me plenty of screenshots and videos which show that the files are not locked.

Does your app explicitly advertise support for this file type in imported file types? It does. I tried only with public.text as well as adding net.daringfireball.markdown (imported with an "equivalent type" with extension "md"), both didn't work.

[quote='852565022, Etresoft, /thread/795994?answerId=852565022#852565022, /profile/Etresoft'] it would have shown up in the top-level list, not in "Other" [/quote] I didn't say that. The app does show up in the top-level list, as I mentioned: "When choosing my app in the "File > Open With" menu, the file opens just fine in my app". And, by extension, you wouldn't be getting that malware warning either. Unless it's a macOS issue as confirmed by a macOS engineer.

The issue is that, when I try to reproduce this on a VM, it doesn’t happen. I tried using a VM (I haven't done so in a very long time), but when trying to download Xcode in it, the App Store kept telling me that my password was wrong, so I couldn't get further. While this is annoying, it isn't at all surprising to me: I wanted to transition from using separate partitions for each old macOS version (to test my apps) to using VMs instead, but quickly noticed that a VM may not reproduce all issues found on a "real" macOS installation, and vice-versa. So up to this day I create a new separate partition on an external drive for each new major macOS version. While installing a new partition blocks you from using your Mac for some time, in my opinion it's worth having separate partitions to test things on, since in my experience a VM is not nearly as accurate as the real thing. In alternative, could creating a new user be an alternative for you? I just remembered that Apple Care always asks to test things with a different user.

[quote='852648022, Etresoft, /thread/795994?answerId=852648022#852648022, /profile/Etresoft'] You were relaying what the end user told you [/quote] I stated the opposite: "This is what happens for me". I only wrote that the user brought the issue to my attention. Never use the App Store. That sounds like a very generic statement and I don't see a reason why not. Would you like to elaborate?

This has been fixed in macOS 26 Beta 2.

[quote='852723022, gnuoyd, /thread/779461?answerId=852723022#852723022, /profile/gnuoyd'] I do not think I am using TextKit 2. I install my own layout manager, and it's my understanding that that disables TextKit 2. [/quote] Could you share some code?

I just created FB19465448. Any help is very much appreciated.

Sadly, I’ve now run out of time to look into this further. I’ll try to pick it up next week. Thanks, I'm looking forward to it. In the meantime, I've created FB19468486.

Thanks. So it sounds like the NSImage is getting over-released or being incorrectly deallocated, although it's unclear to me what exactly is trying to form a weak reference, since my code (as shown above) has a strong reference. Unfortunately the higher up function calls are made by AppKit, which is not open source, so I cannot look it up. As far as I understand, the link you posted helps investigating memory issues in Xcode, but since the crash reports are downloaded by Xcode from other users and I cannot reproduce it myself... The Xcode statistics seem to show that it only happens with macOS 15.3 or newer. I don't know if it's because there's not enough space to show older releases, or if it's really a clue that it's a change introduced with macOS 15.3 that causes this issue. From my perspective it would make sense that it's a new issue with macOS 15.3, because I haven't changed the code that generates or assigns that image in a very long time, and this issue didn't happen for a previous version of my app that was live on the App Store for 6 months (starting from about one year ago) and had barely any crashes (all unrelated to this one). Perhaps it helps to share how the image is created. The result of the method below is directly assigned to myEntity.image in the code I posted originally. Could any of the used APIs have a bug that causes the image to be released incorrectly? private func image(url: URL?) -> NSImage { if let url = url { let imageURL: URL if let volumeURL = (try? url.resourceValues(forKeys: [.volumeURLKey]))?.volume, volumeURL.path != "/" { imageURL = volumeURL } else { imageURL = url } return (try? imageURL.resourceValues(forKeys: [.effectiveIconKey]))?.effectiveIcon as? NSImage ?? NSImage(named: NSImage.folderName)! } else { return NSImage(systemSymbolName: "questionmark.diamond.fill", accessibilityDescription: nil)!.withSymbolConfiguration(.init(paletteColors: [NSColor(white: 0.95, alpha: 1), .systemPurple]))! } }

I don't understand. Aren't all these tools you mention (Zombies instrument, ASan, Main Thread Checker etc.) meant to be run in Xcode or Instruments? Or are you saying I should enable some compiler flag in my production build? The thing that makes over-release issues (and most other memory crashes ) hard to debug is that the crash log you’re looking at is NOT why your app crashed. I'm not sure I understand. Is it correct that the line in the crash log myEntity.image = newImage is trying to retain an image that was over-released or is being deallocated, but the thing that over-released it is possibly somewhere else? What thread is myEntity.image accessed on? I mentioned in my original post that it's called on the main thread, and I just checked again and can confirm it. Just to be sure, I'll put a if !Thread.isMainThread { preconditionFailure() } in the next app update, so there won't be a shadow of a doubt anymore. Though it will take a couple weeks before the update is published and the first crash reports will start coming in again. This brings me to: Seeing that code wouldn't actually help. Even not if we assume that it all happens on the main thread? Could there be something else wrong with my code, or could this be a bug in how these images are created by Foundation / AppKit?

[quote='853568022, gnuoyd, /thread/779461?answerId=853568022#853568022, /profile/gnuoyd'] My custom cursor replaces the AppKit default cursor in every instance on Ventura. [/quote] Previously you said that it didn't work consistently. So does it work now? Since you're using TextKit 1 (by explicitly accessing layoutManager), that's expected: I managed to make it work with TextKit 1 as well, but was asking about TextKit 2, where it doesn't work.

they actually CREATE crashes Thanks, that's what I should have known but didn't fully realize until now. I just tried enabling the Address and Thread Sanitizer (the Main Thread Checker is already enabled), but couldn't reproduce the crash. I'll keep them enabled in the hope that they will create a crash at some point. whatever is going on doesn't involve some simple code flow I could understand that this crash could be caused by multiple threads releasing the image at the same time, but if only the main thread is accessing them, I cannot imagine how they could be over-released. I'm not doing any manual memory management with them or their parent object. If you have any example of how over-releasing could happen without thread contention and manual memory management, I'd be eager to hear it. Otherwise I'll let you know as soon as I'm able to reproduce the crash.

Ah, I confused the macOS names. Can you show the code with your override and custom drawing?

[quote='853647022, kthchew, /thread/795994?answerId=853647022#853647022, /profile/kthchew'] Also, not sure if the original poster's app is sandboxed, but if your app is sandboxed then it looks like the situation is potentially worse: [/quote] My app is sandboxed, and I'm not sure if I ever saw the wording you encountered. But that it indeed worse. In either case, the default action is to move the file to the bin. You're absolutely right (and I failed to point out) that these alerts make the user think that something's wrong or suspicious with the app, and possibly uninstall it. Personally, since the file can be opened once with "File > Open With", I don't see a reason why opening it permanently with "File > Open With > Other" would need such a scary alert.