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?

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]))! } }

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.

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

[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?

This has been fixed in macOS 26 Beta 2.

[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?

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='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.

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='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.

I see, thanks. I'd prefer to stay away from deprecated APIs, but if a user complains about the speed when copying between SMB volumes, I'll come back to this topic. Perhaps the only remaining question would be: how would I find out if the Carbon API / the SMB volume effectively supports cloning, or is it not possible?

Thanks for your insights. how long is the deepest file path? Not long. In the video they showed how the removed directory is only 2 levels deep and every filename is 10-20 characters long. Are you able to remove the sub-directory they added? Like I mentioned, with FileManager.removeItem(atPath:) I wasn't able to, but with my custom function below that recursively removes files before the containing folder and I sent to them in a test app today, it worked (and no error alerts were shown). (Note: before macOS 10.15, the code will leave empty sub-directories and try to remove the top-level directory at the end.) func removeFileRecursively(atPath path: String) -> Bool { if case let url = URL(fileURLWithPath: path, isDirectory: false), (try? url.resourceValues(forKeys: [.isDirectoryKey]).isDirectory) == true { var options: FileManager.DirectoryEnumerationOptions = [] if #available(macOS 10.15, *) { options.insert(.includesDirectoriesPostOrder) } guard let enumerator = FileManager.default.enumerator(at: url, includingPropertiesForKeys: [.isDirectoryKey, .isUserImmutableKey], options: options, errorHandler: { url, error in NSAlert(error: error).runModal() return true }) else { return false } while let url = enumerator.nextObject() as? URL { let isDirectory = (try? url.resourceValues(forKeys: [.isDirectoryKey]).isDirectory) == true let shouldRemove = if #available(macOS 10.15, *) { !isDirectory || enumerator.isEnumeratingDirectoryPostOrder } else { !isDirectory } if shouldRemove { do { if try url.resourceValues(forKeys: [.isUserImmutableKey]).isUserImmutable == true { try (url as NSURL).setResourceValues([.isUserImmutableKey: false]) } if #available(macOS 10.15, *) { let result = if isDirectory { rmdir(url.path) } else { unlink(url.path) } if result < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } } else { try FileManager.default.removeItem(at: url) } } catch { NSAlert(error: error).runModal() return false } } } } do { try FileManager.default.removeItem(atPath: path) } catch { NSAlert(error: error).runModal() return false } return true }

[quote='848663022, DTS Engineer, /thread/791665?answerId=848663022#848663022'] This is a known limitation of the macOS smb client [/quote] Thanks for confirming. Hopefully one day it will be implemented. I created FB18783115.

The user sent me a video showing how removing regular files and empty directories works, but removing non-empty directories doesn't work. They even created a new directory, put a file in there and tried to remove the directory: it didn't work, and after moving the contained file away, it worked.