Utility for macOS that modifies the Dock process so that the desktop bar in Mission Control is alway...
The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:
This is a utility for macOS 10.11, 10.13, 10.14, and 10.15 that changes the behavior of Mission Control so that the desktop bar is always full size and showing previews of the desktops, just like it was in macOS 10.10 and earlier. It's for users like myself who really hate that particular change Apple made in El Capitan and find that it constantly interrupts their workflow and causes much frustration.
This is accomplished by injecting code in the Dock process and modifying its behavior. Unfortunately I didn't find any hidden preference for doing this, which would of course be a lot better. Maybe we'll get lucky and Apple will decide to add a proper setting or hidden preference for bringing back the old Mission Control behavior. However we're three major macOS releases in and they still haven't done it, so that probably won't ever happen.
Note: if you don't want to disable System Integrity Protection or are otherwise uncomfortable with an app injecting code into the Dock, then you can try missionControlFullDesktopBar, a standalone app that triggers Mission Control with the full desktop bar without modifying the Dock. It's clunkier and a little harder to set up, but gets the job done.
First, since this utility injects code into the Dock, you must first disable System Integrity Protection. However, it's not necessary to disable it completely — just the parts that prevent you from injecting code into Apple processes. It's not possible to do this when macOS is running normally; you'll have to reboot your computer into the Recovery Mode and disable it from there. Here's how to do it:
csrutil enable --without debug --without fs
csrutil enable --without debug
Back in normal macOS, open Terminal.app
Navigate to where you downloaded the release of forceFullDesktopBar
Execute install.sh as root
That should install the daemon and modify the Dock process. Mission Control is now back to the way you want it. Furthermore, if the Dock should crash or any new users log in, the daemon will automatically modify the Dock process again.
sudo chown root:wheel /Library/LaunchDaemons/net.briankendall.forceFullDesktopBar.plist
sudo chmod 644 /Library/LaunchDaemons/net.briankendall.forceFullDesktopBar.plist
sudo launchctl load /Library/LaunchDaemons/net.briankendall.forceFullDesktopBar.plist
Either run the provided uninstallation script (uninstall.sh) as root, or delete all the files listed in the manual installation instructions yourself and then execute the following as root:
launchctl remove net.briankendall.forceFullDesktopBar
forceFullDesktopBar can be executed on its own, and has two command line arguments:
When forceFullDesktopBar is not run as a daemon, it will try to inject its payload into all the current Dock processes (or just the ones for one user if -u is used) and then exit. The launchd property file (net.briankendall.forceFullDesktopBar.plist) will launch the process as a daemon when the system starts up and ensure it keeps running.
forceFullDesktopBar requires both bootstrap.dylib and dockInjection.dylib in order to work. It will first look for both files in the current directory, and if it doesn't find them, it will look for them in /usr/local/forceFullDesktopBar/
Unfortunately I was never able to find a suitable method of accomplishing this in macOS 10.12's version of the Dock. Starting in 10.13, having the cursor be at the top of the screen would cause Mission Control to open with the full desktop bar, which provided a new means of hacking it. But in 10.12 it would probably require manually overriding a function by its address, which is fairly unstable and dangerous. I'd rather not do that. Fortunately not many people are running 10.12 any longer so I don't think it's too big of a deal that it's not supported.
You might be thinking that injecting code into the Dock process sounds pretty fishy, and are suspicious of this software. You also might not like the idea of disabling System Integrity Protection. These are all valid worries and if you feel strongly that they're worrisome enough to prevent you from using this tool, then you probably shouldn't.
That said, I'm not too worried about disabling System Integrity Protection. For one, the only part that has to be disabled is the part that restricts debugging and injecting code into Apple processes (and filesystem protections in 10.14). That's a new security measure starting with 10.11, and for all previous versions of macOS I never had a problem with any software, malicious or otherwise, injecting code into Apple processes and causing problems. Never. I haven't even once had a piece of malware get onto one of my macs, and what malware I have encountered on other people's systems generally doesn't need to inject any code into Apple processes. It can wreck havoc on your computer, steal your data, or cause annoying ads to pop up uninhibited with SIP running, provided someone made the unfortunate mistake of giving it root access by typing in their admin password when they shouldn't have.
As for injecting code into the Dock process, in macOS 10.11, the particular way forceFullDesktopBar modifies the Dock is quite safe. You can look at the source code yourself — dockInjection.m in particular — if you want to, but the only thing it's doing is dynamically swizzling the _missionControlSetupSpacesStripControllerForDisplay:showFullBar: method of the WVExpose class. The new method its replacing it with just calls the old method, except it passes in true for the showFullBar parameter. It's hard for there to be a more clean and safer way to change an app's behavior through injection than something like that — there's no question what the 'showFullBar' parameter is for!
In macOS 10.13 and later it's a little bit more hacky, but still relatively safe. Methods are still being replaced by name or by a visible symbol in the binary, and the way the behavior of the Dock is modified is unlikely to cause any serious issues as it's tricking the Dock into thinking that the mouse cursor is at the top of the screen for the moment that Mission Control is activated. This only happens when entering into Mission Control, and the Dock's behavior shouldn't change in any other circumstance.
Anyway, if something does go wrong as a result of using this software, which I admit is always a possibility especially with shady stuff like code injections, all you have to do is terminate the process and restart the Dock process to get back to normal. Or if things get really screwed up, just delete the forceFullDesktopBar binary and/or LaunchDaemon plist and reboot.
When I first started using El Capitan, I immediately knew I was going to have a hard time with the new Mission Control UI. My muscle memory is pretty hard-wired to move the cursor to specific spots on the screen to change desktops. Furthermore, the new way of interacting with it is very problematic. Let me break it down.
Negative effects of the new Mission Control UI:
And just to be fair, I can identify a few marginally positive effects of this change:
So frankly this is a pretty bad user experience degradation. There's almost no benefit to this change — increasing the vertical area for the windows solves nothing and is completely unnecessary — and it causes a lot of problems. The biggest one, at least for me, is absolutely that it changes the act of switching Desktops via Mission Control from a simple point-and-click operation to something that easily could require me to focus on what the UI is doing. That might seem subtle and nit-picky, but the best UI is the kind that barely requires any thought when using it, or what thought you are engaged in is just thinking about what you're trying to do, e.g. switch windows or desktops. Problematic UIs require you to focus on the actual UI and figure out how to accomplish whatever it is you're doing, and this change to Mission Control moves it from the former to the latter.
This project uses code from James Robson's OS X injection tutorial located here.
It also uses mach_inject by Jonathan Rentzsch, located here.
It also also uses fishhook by facebook, located here.