This was surprising for me to see, but it seems that colorfulSidebarX is actually not just using the same method for attempting to approximate missing icon assets, but even using the same plist format(!?)
If you look in /Applications/TotalFinder.app/Contents/Resources/TotalFinder.bundle/Contents/Resources/icons2.plist (long path, I know), you can see for yourself how TotalFinder tries to make its best attempt at trying to map some of these icons back to old assets left over in macOS.
The difference is that colorfulSidebarX seems to be a little more… liberal with how they map some of the icons, to get around the fact that Apple has removed most of the old graphical icon assets in recent macOS versions.
There’s a few choices I don’t really agree with there, like them mapping Documents to… iBooks (which I just find confusing).
TotalFinder, on the other hand, basically just gives up and accepts defeat when an exact (or extremely similar) skeuomorphic icon has ceased to exist, and just falls back to the Finder rendering — instead of doing what colorfulSidebarX does and trying to use icons from other apps (Installer, iBooks, the App Store, etc.) to kinda approximate it.
Setting your own custom sidebar icons in TotalFinder
You can actually already specify your own custom icons in TotalFinder, ever since version 1.9.3 from 〜5 years ago.
This feature just wasn’t documented well (or at all…?) until now.
Make a copy of /Applications/TotalFinder.app/Contents/Resources/TotalFinder.bundle/Contents/Resources/icons2.plist and put it in your home folder (at ~/), naming the file .totalfinder-sidebar-icons.plist
The ~/ refers to your home directory. For example, mine would be /Users/karen/
Open this file in a text editor of your choice and define paths to your custom, bespoke *.icns files from whatever theme you’ve downloaded.
Tip: Press Command-Shift-Period to toggle hidden files on and off in Finder. In macOS (and other UNIX-like OSes), having a dot before a filename or folder name makes it hidden.
※ This shouldn’t happen, but it is possible that some icons may not show up correctly even with your own custom ~/.totalfinder-sidebar-icons.plist on TotalFinder 1.14.1. If this happens, just wait for TotalFinder 1.14.2 to be released, where I’ve fixed that bug.
※ You can also just choose to copy in colorfulSidebarX’s icons14.plist file instead if you happen to like their mappings, but please note that they won’t really work correctly on macOS 10.15 and above (macOS 11 and 12 are even worse) without some manual editing to fix their now-broken icon paths. See the below EDIT section for more information.
※ EDIT
Actually, upon further inspection of the colorfulSidebarX plist, I’m pretty sure colorfulSidebarX will run into the exact same issue TotalFinder does on 10.15 and above.
Quite a few of the “replacement icons” they are trying to reference in the plist simply just do not exist anymore on 10.15 and above.
For some of them (such as their path to Installer.app’s icon, or how Books.app is now at /System/Applications/Books.app), it’s pretty easy to find where the new asset is located (generally AppIcon.icns), but for most other system icons, the icons have been completely replaced with SF Symbols across the entire OS, resulting in the graphical asset no longer existing.
I followed your instructions and it worked! Thank you so much, you’re amazing
Only problem that I’m facing now is that the iCloud Drive icon won’t change, maybe the address is supposed to be different?
This might be a bit off-topic, but I’d appreciate your thoughts. Beyond the shift towards minimalism in UI design at Apple, do you think there are any other reasons (e.g., security, iOS-macOS unification) why Apple removed support for custom icons in the Finder Sidebar?
With recent macOS releases, especially Big Sur and Monterey, Apple seems to imposing a rigid and strict UI design mono-culture that impairs accessibility and usability and removes the user’s ability to customize and enhance the UI for fun or accessibility. I’m not asking for a return of the days of OS 8/9 and OS themes via Kaleidoscope (although that would be nice), but since Federighi took over software development, there seems to a be distinctly arrogant and user-hostile trend reflected in both the restrictive security lockdown of macOS and UI design.
Someone at Apple appears to be opposed to the fun aspects of Apple design that used to exist in the past when Steve Jobs was still running Apple. Even fun little design touches in the hardware were removed like the illuminated Apple on the back of the laptop screens or the rhythmic “breathing” of the sleep light on older models of MacBook Pros.
Anyway, I was wondering if you, as a dev in the Apple ecosystem, have any insight into what’s driving this behaviour at Apple.
@Davi Hmn… yeah, I’ve definitely reproduced the “iCloud Drive and iCloud Shared icons don’t get changed” issue on my end, even on the current 1.14.2 development build.
The issue seems to lie in that Finder appears to be drawing the icons for “iCloud Drive” and “iCloud Shared” in a way that is significantly different from quite literally everything else in the sidebar, including even the dots used for the tags.
See this debug screenshot (where all I forced all Finder sidebar icon lookups to return the exact same custom icon).
The path is correct, though — x-applefinder-vnode:iCloud is how Finder references iCloud Drive on macOS 12.3.1, but they’re clearly rendering/deriving the icon using some other codepath that TotalFinder doesn’t hook into yet.
Thanks for bringing this to my attention, there’s another thing to look into for 1.14.2… (Or more likely 1.14.3, since I do want to try and get the changes made in 1.14.2 released sooner.)
Also, is the icon set that you’re using Flurry, by any chance? I remember that being quite popular in the macOS theming/customisation community back in the day!
I suppose you’re trying to replace the iCloud Drive icon with the iDisk one then?
Oh I see, well it’s not a priority to me the iCloud Drive customization, I’m already happy to be able to change the other icons. Thanks again for all your hard work and explanations!
Yes, it’s Flurry from the IconFactory, it’s funny how these icons fit well today haha
I was trying to use the mobileMe icon on iCloudDrive actually
There aren’t really any security benefits to disabling custom user-defined sidebar icons (if there were ACE exploits lying in Apple’s image decoding/rendering code, that’s a far deeper issue and would be addressed at the framework/library level — trying to mitigate against such attacks in Finder doesn’t make any sense at all).
This decision feels to me more like the UI/HIG department at Apple (or to be more specific, the leadership at the UI/HIG department) either having a very specific creative vision of what macOS “should” look like, and/or just thinking that people who want custom sidebar icons are an extreme minority.
There are two probable possibilities to me — in their user stories, they likely consider “people who want to theme their Finder sidebar icons” to be such a small and insignificant number of people in the grand scheme of all macOS users that they figure either:
① “It’s… probably fine to not add this feature back into our rewrite of Finder, since so little of our users use it.”
… or…
② “We think Finder looks better with these sidebar icons, and we want to discourage users from trying to change it.”
It’s impossible to really know which one it truly is, but I personally feel like it’s probably a mixture of both (maybe more of the first one? Depends on whoever is leading UI/HIG at Apple, and how they feel about these things, I guess.)
It’s actually very interesting to me that you bring up accessibility here.
Personally speaking, I am actually very impressed with Apple’s commitment to accessibility. In terms of the variety of assistive features available in their OSes, as well as the quality of said assistive features, I really do honestly feel that Apple are industry-leading in the accessibility space.
They clearly put in a lot of effort, research, and R&D into making sure they try and reach as many people in need of assistive technologies as possible, and I think it really shows.
This even applies to power-user-oriented features like the Boot Picker on Apple Silicon machines.
Yes, the Boot Picker is fully accessible and navigatable using VoiceOver on Apple Silicon! You can even try it for yourself by pressing Command-F5 at the Boot Picker.
(The reason why this is available only on Apple Silicon and not Intel is because this is only possible thanks to the fact that the Boot Picker on Apple Silicon is actually kind of a stripped-down macOS, unlike the pure UEFI firmware implementation of the Boot Picker found on Intel Macs.)
On a similar note, the FileVault full-disk encryption unlock prompt is actually also fully accessible — and not just only on Apple Silicon (which had full VoiceOver support since debut), but Intel Macs actually received full VoiceOver support at the FileVault unlock prompt on Intel Macs too, as of macOS 11 Big Sur.
The really impressive part of this (to me, anyway) is how much of a technical feat this must have been to achieve on Intel — the FileVault prompt on Intel Macs is implemented as a pure UEFI binary. There’s no OS, no underlying libraries and frameworks to help. To put this into perspective, the best that Apple could do previously on Intel Macs was some meaningful beeping — kinda like POST status beeps on PCs, if you’re familiar with that.
(※ Weirdly enough, the official Apple support page seems to be outdated, and still references the old beeping-only behaviour for Intel Macs.)
All that being said though…
While Apple’s approach to accessibility is outstanding, it definitely isn’t perfect.
Yes, Apple does their best to try and reach as many people as possible. They optimise and develop for the vast majority of people, and for the vast majority of people, I think the assistive features in macOS are excellent.
They even think of the little things, like I mentioned above.
But the issue definitely really comes down to… well, edge cases. The more uncommon and lesser-known needs.
Outside of TotalFinder, I am mostly known on the internet for being an iOS jailbreak tweak developer. One day, I got a request from someone who was a heavy user of a certain tweak I developed that lets you customise many aspects of iOS to your liking. (Being slightly vague because I don’t want to accidentally advertise my own tweaks here, since that feels rude.)
They were asking me if it would be possible to modify the behaviour of the audio balance slider on iOS so that they could specify more granular values than the slider would allow them to, or even numerical values, as the slider in question understandably snaps to the middle for usability / user-frustration-reducing reasons.
After some quick RE work, I quickly figured out how to do that, implemented the new feature, and pushed a beta channel update.
It’s things like that — things that Apple doesn’t think of (or can’t come up with a nice way to make available while still maintaining their UI/UX standards), where third party software could fill the niche… but with some difficulty due to macOS trading off extensibility and flexibility for hardened security.
(※ For the record, just in case anyone reading this has a similar issue to that person I mentioned above, you can replicate the “more granular balance control” behaviour on macOS using the built-in Audio MIDI Setup app, which lets you enter numerical values for how loud you want each audio channel to be.)
Hmn… I have complicated feelings on this.
It is very clear to me that Federighi and other technical/design leadership at Apple actually understand the position of the Mac in their product lineup very well.
The iPhone is a very locked-down device, where jailbreaking (rooting) is practically a need, if you want to change your experience using it beyond whatever Apple allows you to do.
But the Mac represents more of a “traditional” computing paradigm, where giving the user control over it is still rather important.
I’ll be honest — I had… concerns regarding what the security model would look like when Apple first announced the Apple Silicon Macs, given my iOS background.
The removal of extremely useful features that have been around for ageslike Target Disk Mode (I’m still not happy about this, Apple.) didn’t really help, either.
But as they unveiled more technical information on Apple Silicon and how the security model was designed, that mostly put my worries to rest.
Well, except the whole “weakening/disabling SIP will also disable Apple Pay and iOS-on-macOS FairPlay DRM” thing. But that’s probably the fault of the lawyers. They ruin everything. ;P
Apple’s approach to security on Apple Silicon appears to be very much “try to achieve a balance between allowing power users and developers the freedom they want, while making our platform as secure as we possibly can”.
For instance, there’s the entire concept of the “fuOS” (speculated to mean “fully untrusted OS”).
Asahi Linux is a very impressive project that quite literally would not have been possible without Apple designing the Apple Silicon boot chain the way they did.
They even added a raw image boot mode in macOS 12.1, which now allows anyone who wants to run custom OSes on Apple Silicon hardware to not have to deal with Mach-O binaries anymore.
And if you’re the kind of person who likes compiling your own XNU/Darwin kernel from source (see this “Apple Kernel Development” blog), you can boot your own compiled and codesigned mach_kernel images on Apple Silicon! (… Though I’ll be honest and say I’m not sure why you would ever want to do this, aside from the novelty of doing so.)
Tools like kmutil and bputil, as well as the Apple Platform Security Guide also show that they want people to understand the Apple Silicon security model, and to experiment with it if they like.
Basically, the gist of what I’m saying here is — it would have been very easy for Apple to not have expended the loads of engineering effort it must have taken to implement the Apple Silicon boot process in this developer-friendly way. It would have been way easier for them to have just done what they currently do on iOS devices.
I suppose what I’m trying to get at here is that I don’t think Apple are really trying to be purposefully user-hostile, at least when it comes to the design of their security model.
It’s not like Apple are unaware of projects like Asahi Linux (… or maybe even TotalFinder…? ;P) — they’re not going to go out of their way specifically to break these projects.
I find that it’s rather the opposite — Apple won’t ever come out in full support of any third party projects like these, but I do think they at least try to not actively break things… that is, when they can help it.
Overall, Apple are definitely a company that… pretty much kinda just does their own thing without caring too much about other people. They answer to themselves first and foremost (as do most other companies, albeit perhaps to a lesser degree).
… But they definitely at least keep an eye out for how people are actually using their products in the field.
Here’s another example I can think of — the Homebrew package manager.
Back when Apple introduced SSV (Signed System Volume) in macOS 10.15, we quickly noticed that one of the writable firmlinks (see cat /usr/share/firmlinks) included in the default set had /usr/local in there.
Why was it there? Probably because of Homebrew. They’ll never officially acknowledge that Homebrew exists, but they were aware that a change they were making to improve overall platform security would otherwise break Homebrew, so they tried to avoid that by adding /usr/local as a firmlink.
I’m not sure if what I’m saying here really makes sense, but hopefully you understand what I mean.
… This post is getting really long, so I’ll try and end this soon (sorry l o l)
I do think that Apple’s focus on their platform security across all appleOSes (my own personal term encompassing macOS, iOS, tvOS, audioOS, etc.) is overall, a good thing.
I feel that Apple treats security as a priority by design, especially given their full control over the entire stack of not just the software, but even the hardware. There are many security features that are only possible thanks to custom features in Apple Silicon, and generally speaking, these are features that benefit even people who choose to weaken/disable SIP, like us TotalFinder users.
I simultaneously understand why things like SIP exist, and how they improve platform security for the vast majority of macOS users (allowing third party code to inject into system processes is a security concern, definitely) — but I also understand that this impedes and makes it difficult for third party developers to augment and enhance macOS in the ways they like.
Quite honestly, I’m not really sure if there is a “solution” per se to this issue. If you want security, you have to give up system tweaks. That’s just… how security works.
It’s similar to the whole performance vs. user-upgradability problem Apple have with Apple Silicon right now. You can either have user-upgradability via SODIMM modules, or you can have ridiculously fast, low-latency, and low-power ECC(!) RAM on-die. Not both.
Do I wish the reality was different? Of course. I would love a fully user-upgradable Mac, and I would definitely love it if the flash storage was actually on its own separate, removable module (which, to be fair, the Mac Studio does) and that there was some way to read out such an SSD on another system in case of catastrophic system failure.
For the former, that’s unfortunately just… not how physics work.
And for the latter… that’s just how Apple has designed FileVault encryption for the internal flash storage on Intel T2 and Apple Silicon Macs. (See: xartutil and the whole concept of xARTs in general.)
That being said though, I feel like being able to still access the data from a removable SSD from a dead machine like you can with a Windows machine or an older Mac is also very important.
It’s definitely possible — BitLocker on Windows behaves similarly with regards to SSD transportability between systems, since the encryption key is stored in the TPM. But in that case, the BitLocker recovery key can be used to decrypt the SSD on a different system, if needed. (One can argue that the existence of such a recovery key that can be used in this way arguably “weakens” the security in a way, though.)
(… That being said, BitLocker has a really long way to go before I feel like it’s ready for usage by most people, in my opinion. I’ve seen too many data loss horror stories, from both friends and random people on SNS.)
Aside from all that, the only other real complaint I think I have with how Apple Silicon works right now, is well… the whole “weakening/disabling SIP also disables Apple Pay and iOS-on-macOS FairPlay DRM” thing. But that’s almost definitely not a technical decision, but rather probably due to lawyers meddling with things, if I had to guess.
Also, this will sadly probably never happen, but I also wish that Apple Silicon machines supported standard UEFI like other consumer ARM machines on the market (like the Surface Pro X, etc.) and/or was compliant with ARM SystemReady (previously known as ARM SBSA). But that’s just wishful thinking at this point.
I feel like this is again, probably just a result of different people working at Apple and its various departments’ leadership now.
Regarding the rhythmic “breathing” LED behaviour — while I do understand why the cutout and accompanying LED was removed from the MacBooks… (It was already difficult to manufacture to begin with, required specialised equipment, and probably just started taking up too much space for a “nice touch” that they probably figured people wouldn’t miss too much.)
It is certainly a bit odd to me that on other Apple devices that still have a power LED (like the Mac Studio, Mac mini, or even the Mac Pro), the breathing effect is still gone. That I genuinely have no explanation for, and am wondering the same thing.
And as far as the glowing Apple logo goes… (I miss it, too!)
For the USB-C / Touch Bar / T2 and T1 era MacBooks, I feel like that was a decision done just to make the panel as thin as possible.
And on the M1 Pro / M1 Max era MacBooks… while the lid design is now thick enough again to allow the glowing Apple logo to return, I feel like the fact that the panels now use localised backlight dimming technology is probably what ultimately caused the M1 Pro/Max MacBooks to retain the polished metal Apple logo.
… It’s either that, or someone on the industrial design team just really doesn’t like the glowing logo, for some reason. ;P
tl;dr
As someone who works in the Apple ecosystem, I feel like this is probably the most apt general interpretation of Apple:
Apple doesn’t [restrict system extensibility / invent their own standards / make memory non-replaceable / create weird SSD modules that are basically just raw NAND chips on a card] just to make your lives more difficult, or spite their users.
They generally do these things because they have a good reason for doing so (or they think they do), whether that be in security, performance, or perhaps they’re just unhappy with the state of whatever the current standard may be, and think they can do better.
It can be frustrating, yes. And they’re definitely not always right.
But overall, I feel like most of what they do is for the better, especially if you understand what they’re doing on a technical level.
Thank you for your detailed response. It’s always nice to get a software engineer’s thoughts on Apple’s software and hardware decisions. It helps me to view Apple from a different perspective.
As for my accessibility concerns, I’ll briefly clarify what I meant. I agree that Apple has done a lot for accessibility and has a great many accessibility features.
My complaint is primarily about the default visibility of the UI of macOS. Especially with Big Sur and Monterey, Apple seems to be designing the UI to appeal best to young people with superb vision. All the transparency features that are on by default in Monterey are one example of something that causes problems for middle-aged and elderly people. And in Monterey, it’s become more difficult to distinguish between a foreground window and a background window. There’s a lack of depth and definition.
Fortunately, there are ways to mitigate this via System Preferences, but they’re buried. My middle-aged and elderly family members have no idea where to find these settings and so inevitably they call me.
There are other poor UI features I could mention (e.g., the stupid hidden Show/Hide button in Mail’s sidebar that only appears when you mouse over it) but this is off-topic and I really should write a detailed complaint/plea/argument for Apple Feedback in the hope they would make some changes.
Huh. I must admit, I’ve never thought of Apple’s new, post-macOS Big Sur UI in this way before, speaking as one of said “young people with superb vision”.
Anecdotally, none of my middle-aged (or older) family members have ever complained to me about the UI on either macOS or iOS as being difficult to “read” (for the lack of a better word) before.
They’ve generally only asked me regarding increasing the font size (Dynamic Type), and in the case of iPhones, enabling the larger UI scaling as well (where iOS will use the internal render resolution intended for a 4-inch display, but scaled up on the larger 4.7-inch display instead).
(… That being said, I also haven’t spoken to any of said family members in a long while now, considering their… hostile stance on the fact that I happen to like women.)
Curious — back when Aero was being used in Windows 7 and Windows Vista, did these people have the same issues with that UI design as well? Or were they always Mac users?
Aero also had a lot of transparency in its design, even moreso than modern macOS which goes for more of a translucent, “frosted glass” look.
Hmn, yeah. I feel like Apple should probably consider asking users if they would like to enable the high-visibility / high-contrast UI as part of the post-upgrade or new-install (OOBE) onboarding process — it would definitely increase discoverability of that feature even existing to begin with.
… It might also just already be there, but hidden away in the “Would you like to enable any accessibility features?” prompt (the one with the “Vision”, “Motor”, “Cognitive”, etc. buttons), which kinda leads into the next thing…
Yeahhhhh… UI discoverability in newer versions of macOS and iOS definitely need to be improved, I feel. There’s lots of features just hidden away in often strange ways, causing many users to not know that they even exist to begin with.
Even things like the Document Proxy Icon (the little icon normally at the top of the titlebar) require a rather undiscoverable mouse-over to reveal now, at least in Finder.
I think I’ve had at least six or seven different people contact me in a panic, saying that they’ve “lost their email”. I know immediately what the issue is: they’ve accidentally clicked on the “hide” button in the Mail sidebar and hidden their mail folders.
The fact that they don’t know they did this or how, nor how they can restore their email by “unhiding” it, is mostly due to bad UI design or poor UI discoverability, as you said.
And yes, Apple choosing to hide the proxy icon is another baffling decision. I guess I just need to calmly ride the waves of their design whims and experiments and screw-ups.
So, I just discovered that if you type or paste an emoji into the name field of a folder (e.g., rename a folder with an emoji) and drag the folder into the Finder sidebar, the emoji will be displayed next to the folder icon.
Why would Apple remove custom folder icon support in the Finder sidebar but display emojis in folder names in the sidebar?
@strafer Apple didn’t really specifically go out of their way to add this functionality into Finder, it’s just a natural result of the fact that Finder (and most macOS/iOS/etc. apps) use their CoreText framework to handle font rendering, and CoreText on all appleOSes just also happens to be able to handle emoji rendering.
Hmn, this is… a very strange issue you’re running into.
I can’t reproduce this, nor have I ever seen this happen — at least, not on 11.6.5.
I’ll try installing 11.6 later when I have time, and see if I can get this to happen.
A simplified explanation of your issue would be that for some reason, the AppleScript runtime on your system somehow doesn’t seem to be aware that TotalFinder is even installed.
Or for a slightly more technical explanation, our custom AppleScript event handlers used by the TotalFinderInjector component that lives in /Library/ScriptingAdditions/TotalFinder.osax aren’t being detected or registered by your system’s AppleScript runtime.
Basically, TotalFinder.app fires an AppleEvent called BATFinit. Upon receiving this event, AppleScript performs a lookup against all AppleScript event handlers, both built-in and third-party (“ScriptingAdditions”), to see if anything is capable of handling that event.
On a working system, AppleScript would find that TotalFinder.osax is capable of handling BATFinit, and then it will pass the event to it, which then results TotalFinder being activated.
Uninstall TotalFinder, using the TotalFinder Uninstaller.app from the downloaded DMG.
Reboot your Mac for a clean state.
Reinstall TotalFinder from the PKG.
You won’t have to re-do any of the Apple Silicon steps or anything.
If the issue still persists… I will try and get macOS 11.6 installed on a test machine and see if there’s some strange bug specific to just that version.
※ EDIT: Also, if you haven’t already, please try the instructions on this page.
