QLThumbnailGenerator macOS 26.4 No Longer Honors Users 'Folder Color' Preference When Making Icons for Folders

I see that too. Luckily, I only use the new QLThumbnailGenerator flow if the url has the "com.apple.icon.folder#S" extended attribute. I'm sure that's an "implementation detail", but still a good idea. Most folders display properly and immediately. It's only the folders that are customized using the new system that don't appear correctly.

Hello Macho Man Randy Savage,

Thank you for reporting this issue! We are tracking it as FB22340558 accordingly. Thanks also to Etresoft for the confirmation.

Best regards,

Richard Yeh  Developer Technical Support

I see that too. Luckily, I only use the new QLThumbnailGenerator flow if the url has the "com.apple.icon.folder#S" extended attribute. I'm sure that's an "implementation detail", but still a good idea.

How are you getting the icon otherwise? NSWorkspace gets the folder color right but it gets other things wrong.

Quicklook thumbnailing gets the other things right, but now it gets the folder color wrong.

A non-empty folder results in an icon with paper sticking out on macOS Tahoe but an empty folder doesn't have the paper sticking out. NSWorkspace seems to get everything right on 26.4 (it didn't before otherwise I would have went with it) but only when a custom SF symbol/Emoji is set as far as I can tell.

And Finder has its way of being exempt from all of this, natch!

How are you getting the icon otherwise?

It's not quite "otherwise".

Normally I just use "NSWorkspace.shared.icon(forFile:)". But folders require special logic.

If the folder name has a "." prefix, then I call "NSWorkspace.shared.icon(for: .folder)". I'm not sure why. Probably should have commented that.

But if the folder doesn't have a "." prefix, I use the standard "NSWorkspace.shared.icon(forFile:)". Then, I check to see if I need to do more. I the URL has the "com.apple.icon.folder#S" extended attribute, I try QLThumbnailGenerator.

QLThumbnailGenerator is async anyway, so it really always requires the two-step process.

A non-empty folder results in an icon with paper sticking out on macOS Tahoe but an empty folder doesn't have the paper sticking out.

Interesting. I didn't realize that. However, it doesn't seem to always work. I just now figured out that if the folder has a "." anywhere in the name, then it will display in the Finder as the old default, empty folder, even if it has contents. If you remove the "." then it will add the paper.

And Finder has its way of being exempt from all of this, natch!

But of course!

Edit: This is strange. There's some kind of heuristics in the Finder. You can put a "." up towards the beginning of a folder name and it displays correctly. But if the "." is towards the end, then it reverts to the default folder appearance, losing any "modern" folder customization.

Ironically enough, adding a "." doesn't affect the old folder icon customization method, which, from what I hear, is completely broken on Intel.