@Ronald_Epstein That’s… very strange and certainly should not happen.
I am really sad that I can’t use TotalFinder under these conditions
Don’t worry, I’m here to try to help you get this working! (And possibly improve the documentation, if it was confusing)
I already had SIP disabled for another app I was using so no big deal.
What app was this? Also, did this app instruct you to disable SIP (using csrutil), or did it only require you to lower security settings to “Reduced Security”?
However, when going into my M1 recovery and lowering security settings as described in the support tutorial, all hell broke loose…
If you already had SIP disabled, all you really had to do was Part 3 in the instructions — following Parts 1 and 2 wasn’t really necessary (although it wouldn’t have hurt, anyway).
Can you tell me exactly what changes you made and at what point errors started coming up? If not, please just try again following the instructions exactly to the letter, from Part 1 all the way to Part 3.
(Also, which apps/plugins broke?)
The state that you are describing sounds like to me that you had rebooted back into macOS immediately after completing Part 1 of the instructions, which actually does re-enable SIP temporarily.
SIP is only disabled after following Part 2. It is possible that this is the reason why everything started asking you to re-disable SIP.
Please note that if you had booted back into macOS after Part 1 but without completing Part 2 in the guide, SIP actually is enabled. Basically, here’s a summary of what each step does:
Part 1: Putting your system in “Reduced Security” mode actually re-enables SIP if you had it disabled previously.
Part 2: As a result, we go back into “1TR” (one true recoveryOS, aka the hold-power-button recoveryOS) and run csrutil to disable SIP.
Part 3: This is done inside macOS and basically involves just creating a file in your home directory.
Please let me know if you have any more issues — I am determined to help you get TotalFinder working on your system ;P
Would it be a lot of work add an option for rectangular tabs like this?
If it’s a non-trivial amount of work to implement this, don’t bother. You’re already spending a lot of time fixing TotalFinder for Monterey and M1 Macs.
The reason I already had SIP disabled was that another software app required it. I think the app is SoundSource.
I am aware that re-installing Mac OS re-enables SIP so the first thing I did when I reinstalled Monterey was going in and disable SIP again.
So, right now, SIP is disabled and I am NOT on reduced security. You are saying that all I need to do is follow step 3? That looks simple as it’s just a terminal command. Let me try it and I’ll let you know if I get TotalFinder working.
Once again, very much appreciate the level of support here
EDIT: Just re-installed TotalFinder and used the terminal command and then disabled some sort of library check at startup and IT WORKS!
So happy to have TotalFinder back. Thanks so much!
Hey @Ronald_Epstein, I have SoundSource too, and I was initially confused when I went into recoveryOS and was already on Permissive Security. So I ended up raising the level, to the recommended Reduced Security setting.
Well, it was either SoundSource, the RME drivers, or Paragon NTFS that had previously sent me there.
Anyway, it turns out that the Reduced Security setting that @akemin_dayo has specified is enough for all these kernel extensions, so that’s great.
I too am incredibly happy to have TotalFinder back on my M1 Pro. And Karen, your detailed support in this thread has been wonderful. Thanks.
The great thing is that I only had to turn off SIP.
The problem I had was when I turned on reduced security, I had problems with so many apps either asking for extra permissions at launch or plug-ins (like MailButler) not working at all.
@strafer This would unfortunately involve reworking quite a bit of the tabs rendering code in order to get it working and making it look good / coherent.
I’ll note this down as a feature request, but it’s unlikely this will come anytime soon — sorry about that.
The current version of the documentation doesn’t really address users that already have SIP disabled, which was a massive oversight on my part. I’ll push an update to it to better help future users.
(On a side note, I also use SoundSource/Audio Hijack/…Rogue Amoeba ACE apps in general, as well as Paragon NTFS ;P)
@Peter_Hollo I’m glad that TotalFinder is working for you! However, I do want to clarify that you are actually not in “Reduced Security” mode.
You are still in “Permissive Security” (SIP disabled or weakened) mode.
What the steps you followed did, was that it had you temporarily raise it to “Reduced Security”, before lowering it back down to “Permissive Security” (SIP disabled or weakened).
A detailed explanation of why I had you do this seemingly-pointless procedure can be found below, if you would like to read it.
@Ronald_Epstein While the configuration that you are describing (“I went straight to disabling SIP without first changing my system to Reduced Security before doing so”) is valid, please be aware that there is a reason why my instructions tell you to go to Reduced Security first.
A detailed explanation of why I had you do this seemingly-pointless procedure can be found below, if you would like to read it.
In which I attempt to write a simplified-yet-informative explanation of the Apple Silicon security model
The core issue that I’m dealing with here lies with the very confusing way that Apple has chosen to design their user-facing tools for modifying Apple Silicon security features.
So, the TotalFinder documentation instructs users to perform two major steps concerning SIP:
Set your system to Reduced Security mode, and allow user installation of kernel extensions (kexts).
Reboot back into “1TR” (hold power button) recoveryOS, and then use csrutil to disable or weaken SIP, which results in your system being put into what Apple calls “Permissive Security” mode.
You may have noticed something strange about this already.
… Why exactly is it that I am instructing users to lower their security twice?
Why do we have to make a stop at “Reduced Security” through the System Startup Utility before we can run csrutil to disable SIP and reach “Permissive Security”?
Why don’t we just skip Step 1 entirely? (← @Ronald_Epstein, this is what you did, if I’m understanding what you wrote correctly.)
The answer lies with some deeply strange and bizarre design choices from Apple.
Understanding the Apple Silicon BootPolicy LocalPolicy
The security architecture and design of Apple Silicon Macs are very different from how things worked back on Intel (x86_64).
One major difference lies in the existence of something Apple calls the BootPolicy LocalPolicy, which is heavily documented in their Platform Security Guide.
The BootPolicy (which, by the way, is per-OS, hence “LocalPolicy”) contains various flags that tell macOS to enable or disable certain security features.
You can view your current flags using sudo bputil -d in a Terminal session.
As you can see here, the “Security Mode” (FourCCs smb0 and smb1, if you want to follow along in Apple’s documentation) is Permissive, and the SIP status (sip0) is 7f (“fully disabled” — if you’re running a partially-disabled SIP configuration, you will have a different sip0 value, which is fine).
But have you noticed something here?
There is a completely separate entry for “3rd Party Kexts Status” (smb2).
… So what does this mean?
Trying to prevent users from shooting themselves in the foot
In the software engineering community, we’ve coined a word for tools that have a large potential for users to accidentally “shoot themselves in the foot”, so to speak.
We call them “footguns”, and Apple just handed you a pretty big one.
Basically, when you run csrutil to disable or weaken SIP, you are in fact, ONLY changing the Security Mode and the SIP Status.
By disabling SIP without first using the Startup Security Utility, you will end up in a state where you cannot use kernel extensions (kexts), even though you have SIP disabled or weakened.
“But wait,” you ask, “can’t I just enable kexts later if I need them?”
Ah.
So about that.
The “Startup Security Utility”, due to some utterly incomprehensible reason, does not let you enable kexts unless if you are in “Reduced Security” mode. The options are quite literally greyed out.
What happens if I disabled/weakened SIP without first going to Reduced Security mode?
Let’s say you don’t use any kexts right now. You install TotalFinder, and you disable SIP without first going to Reduced Security mode.
Some time passes, and you find yourself wanting to install a kext. Maybe you want to…
Use OpenVPN or SoftEther VPN, both of which require TunTap
Write to an NTFS disk, which requires Paragon NTFS
Update your Sony Alpha mirrorless camera, which requires the “Sony Camera Driver” kext
Charge USB devices at high wattages through your CalDigit Thunderbolt dock which requires the “CalDigit Thunderbolt Station Charging Support” kext
… and more.
So now you want to install kexts. But the software you’re trying to install keeps yelling at you, telling you to enable “Reduced Security” mode and allow kexts.
“Wait, but how does that make any sense!?” you ask, exasperated. “I’m in a mode even less secure than that, I’m in Permissive Security mode!”
After some research, you come across this thread, and realise that you have to:
Boot into 1TR recoveryOS, and temporarily upgrade your security to Reduced Security mode.
Now, you can check the box to allow kernel extensions (kexts)!
… But now you’ve rebooted back into macOS and TotalFinder is broken now, because SIP was re-enabled when you upgraded to Reduced Security mode.
You let out a heavy sigh, boot into 1TR recoveryOS again, and disable/weaken SIP again via csrutil, which downgrades you right back in “Permissive Security” mode, but now with kexts enabled.
This kind of ridiculous, headache-inducing situation is what I want to avoid for users.
This is why I specifically wrote the documentation to instruct users to to first set their systems to Reduced Security, and then further down to SIP disabled/weakened (aka Permissive Security).
This way, I make sure that pretty much every conceivable user is covered under my instructions, no matter if they are already using kexts (but may not necessarily know / remember), or if they are currently not, but may do so in the future.
Basically, by following my documentation, your system will be in the correct state for pretty much any macOS software you’ll run into in the future.
The current version of the documentation and its shortcomings regarding users that already had SIP disabled for other software
So what happened with you guys?
I’ve come to realise that the current version of the documentation doesn’t really do a good job at communicating to users that if they already have SIP disabled, they don’t actually need to follow Part 1 and Part 2 — and instead they can just go directly to Part 3.
That being said, there wasn’t actually any harm in following the instructions anyway, even if you already had SIP enabled.
What probably ended up happening though, was that you may have been led to feel like you’ve accidentally done something wrong.
You see, if you followed the instructions, you actually ended up raising your security level (to Reduced) by following Part 1, before lowering it back down using csrutil in Part 2.
This operation does not affect any of your other apps in any way, since you will end up back in a SIP disabled/weakened state (Permissive Security) anyway.
However, if booted into macOS after Part 1 (instead of directly into 1TR recoveryOS again for Part 2), all of your software that required SIP to be disabled probably started yelling at you, which likely made you feel like things went horribly wrong.
Following through with Part 2 (disabling/weakning SIP again) would have solved all of that, but I understand why you were perhaps apprehensive about doing so.
Either way, I’ll update the documentation sometime soon to better handle the SIP-already-disabled state, so future users won’t be confused!
Hopefully this entire explanation all makes sense to you.
※ I’ll probably end up editing this post several times since I feel like I could be clearer in a lot of parts, but hopefully this gives you a better understanding of everything.
Wait… Karen, one last thing — what about bputil -k? Won’t this allow users to disable SIP and allow kexts in just one launch of 1TR recoveryOS?
…
So remember what I said earlier about footguns?
bputil is such a massive footgun that Apple actively discourages you from using it to modify your BootPolicy.
(Running sudo bputil -d like mentioned above is fine, as it’s a read-only operation — it doesn’t change anything.)
This utility is not meant for normal users or even sysadmins.
It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery ("recoveryOS").
It is possible to make your system security much weaker and therefore easier to compromise using this tool.
This tool is not to be used in production environments.
It is possible to render your system unbootable with this tool.
It should only be used to understand how the security of Apple Silicon Macs works.
Use at your own risk!
So yes, while running bputil -k to enable kexts and then telling users to disable/weaken SIP using csrutil definitely makes the guide way easier… (and it can all be done with just one trip to recoveryOS!)
I feel like it would be extremely irresponsible of me if I encouraged users to use such a tool.
While it is true that nothing should go wrong as long as the user makes sure that they only type bputil -k, the potential for error is very large if, for instance, a typo is somehow made. (See man bputil for all the things this tool can do — it can even disable SSV!)
I’m not exaggerating when I say that bputil can definitely end up making your system unbootable, if you touch the wrong options.
Of course, if you’ve read up on the Apple documentation and you understand how the BootPolicy works and how to recover from any potential screwups, by all means, go ahead and use bputil! It’s a very useful and powerful tool, and can modify the BootPolicy in a far more granular way than any other tool.
But for everyone else, I will never encourage using this tool, nor will I ever officially put it in a tutorial.
Brilliant. To me this does make sense, possibly because I went through those steps already!
Unfortunately, including booting back into macOS once and yup, getting yelled at by some of the other system extensions I had installed. Oops!
Anyway, all it took was another reboot to get back to the right state. The bottom of my sudo bputil -d output looks exactly the same as what you’ve got above.
Oh my! This is so awesome I can’t stand it!! Working with Apple’s default Finder tab interface is painful at best. So thankful that we were able to get this done. Also glad that the alternate SIP configuration instructions were included. Thanks for that.
Terminal states, however that when you use that config, that its not supported and the machine will likely not be able to boot when those flags are removed. REALISTICALLY, how likely is that to happen? Does anyone know?
@ChrisSpera I assume you’re talking about the warning that Apple gives you in csrutil when you choose to partially enable / weaken SIP (instead of fully disabling it).
For reference for anyone else who’s reading, Apple left a message from csrutil that says this if you try to set a partially-enabled / weakened SIP state:
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
So, what does this actually mean?
As is becoming a… trend for my posts in this thread, it’s time for another episode of everyone’s favourite “Karen attempts to explain yet another part of Apple OS internals”!
In which I attempt to explain Apple’s XNU/Darwin CSR flags
First off, let’s take a peek into Apple’s source code for their XNU/Darwin kernel.
These are all of the CSR flags that exist as of XNU/Darwin version xnu-8019.80.24, which corresponds to macOS 12.2 Monterey (the latest available open-source release of XNU/Darwin).
What are these flags, you ask?
These are what Apple uses internally in macOS to determine which SIP features should be enabled or disabled. By default, they are all enabled.
These CSR flags are what the csrutil tool in recoveryOS is actually modifying. This has been the case ever since SIP was introduced all the way back in macOS 10.11 El Capitan (2015).
Now, do you see those weird (1 << 0), (1 << 1), (1 << 2), etc. things on the right?
If you’re totally lost as to what those numbers mean, those represent bit shift operations. (For those with programming knowledge — yes, the SIP configuration state is a bitmask.)
For the purposes of this explanation, you don’t actually need to know what bit shifts (or bitmasks) are — all you need to know is that they can be translated to a numerical / hexadecimal value.
Here, I’ll do it for you — I’ll also annotate which CSR flags translate to the various csrutil arguments, too.
As you can see, each CSR flag has its own numerical value associated with it.
For reference, TotalFinder requires these CSR flags to be disabled:
CSR_ALLOW_TASK_FOR_PID (0x04 or --without debug)
CSR_ALLOW_UNRESTRICTED_FS (0x02 or --without fs)
Apple’s scary warning when you try to leave SIP partially enabled
Basically, the reason why Apple shows you the scary warning when you try to leave SIP partially enabled (as opposed to fully disabled via csrutil disable), is because they’re basically just trying to cover for themselves, saying “I told you!” if they decide to change what some of these values mean.
They’re pretty much just saying “We reserve the right to change what any of these CSR configuration values mean in the future, and this may cause a different set of SIP features to be enabled or disabled after an update.”
… That being said, Apple has never actually done this in the 7 years since they’ve introduced these values.
I’ve personally been running a partially-enabled SIP configuration ever since macOS 10.11 El Capitan (2015), and well… the values have never changed.
Over the past 7 years, all they’ve done is add new values, not change old ones.
For instance, CSR_ALLOW_UNAUTHENTICATED_ROOT (0x800) was not a CSR flag that existed originally and is a new addition, but CSR_ALLOW_TASK_FOR_PID was always, and still is equivalent to 0x04.
But what’s important to note here is that they can, if Apple ever decides to for some reason.
Will Apple ever change the old CSR values? I don’t know. And unless you’re a time traveller from the future, no one can know.
That being said though, if they ever do decide to do so, what will probably happen is that you’ll just see some SIP features that you previously disabled end up becoming enabled again, which can be corrected by making a trip back to recoveryOS and disabling what you wanted to be disabled again via csrutil.
And even if this does somehow result in your system breaking in some way as per Apple’s warning, a trip to 1TR (hold-power-button) recoveryOS (… or if you’re using an Intel Mac, resetting your NVRAM) will fix everything.
… That was really long, can I have a tl;dr?
It’ll probably be fine. Apple has gone 7 years since macOS 10.11 El Capitan (2015) without changing anything, and I’ve been using such a partially-enabled configuration this entire time.
It was possible to enable custom sidebar icons on Big Sur with XtraFinder, it used a .plist file that pointed to the custom icons, not sure how TotalFinder does it. There’s also colorfulsidebarX from MacForge, I think it works on Monterey but it hasn’t been updated to M1 machines
@Davi The upcoming TotalFinder update will basically “just work” for the colourful sidebar feature — you won’t have to edit any plist files or anything.
Basically, whatever you see in Finder is whatever will show up in the sidebar.
Yes. That’s EXACTLY what I was referring to and thank you SO much for the awesome explanation. I truly appreciate all of your efforts and work. Please let me know how I can help. I’m a Software QA/QE VP with 30 yrs experience. Let me know what I can do.
That’s nice but… macOS always used different icons on the sidebar instead of using the folder ones. Most of the old iconsets on the internet have especially designed icons for the sidebar, so it would be great if TotalFinder used the colored ones by default and we could set our own custom icons if desired.
What I meant in my comment is that XtraFinder automatically changed the sidebar icons to the colorful version, but I could point it to any custom icon if I edited the plist file.
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.
