For those who aren't aware, defaults write is a Terminal command that can be used to modify applications' settings. While you can use these commands to modify settings that are present in an app's Preferences panel, the more-common use of this command is to set non-visible (hidden) prefs that you won't find in the GUI.
Here are three of my favorites—three that not only perceptually but actually increase the speed of your interactions with your Mac. I still, to this day, execute these commands on any new Mac I set up.
Sheets are the attached windows that roll down from (and up into) the title bar of windows, such as the Save dialog in most macOS applications. The animation of these sheets, while visually appealing, does take some time.
Using this tip, you can basically eliminate the animation, greatly speeding the appearance and disappearance of sheets. Given how pervasive sheets are, this tip can save a lot of time each day. While the other tips offer actual speed improvements, they're nothing like the change you get by changing the sheet animation speed.
As a test, I opened and closed a Save sheet in TextEdit five times, both before and after applying this tip:
If you're scoring at home, that's a 47% reduction in the time required for just five cycles of a Save sheet.
To me, the modern view in Apple's Mail app is basically useless: I keep my Mail window at 1,020 pixels in width, because really, there's no need for it to take up more space than that. But at that width, the modern view's message preview is so tiny as to be basically worthless:
Obviously, that's classic view on the left and modern view on the right. With the classic view, I can read each email as soon as I select it in the list; with modern, I have to double-click a message to open in a new window, which is a waste of time and screen space. Modern only gets truly usable if I'm willing to make the window roughly 1,500 pixels in width.
So which layout do you use? Vote in the Twitter poll for the next day (well, 23 hours and counting).
Once a month, I download roughly 25 gzipped (.gz) files from Apple—these are our Mac App Store sales reports, with one file for each App Store region. I could have Safari expand these files (via the "Open 'safe' files after downloading' item in its preferences), but I prefer to leave that option unchecked. (Why? I often download archives that I want to leave archived, and I like to keep originals of many of the things I download).
If you work with lots of compressed files, you're probably familiar with what happens in Finder (see note) when you go to expand any semi-large number of files: The infamous Dancing Dialog™. It looks something like this…
[Note: Technically, this isn't Finder, it's Archive Utility doing the expansion. But this is the service that Apple provides to expand compressed files, and it's what 99% of macOS users will use. It can be changed via the Get Info dialog, but very few people will take that step. So to most users, it seems it's Finder handling the expansion. For ease of reference, I'm going to say it's Finder doing the expansion.]
Not only is this randomly-resizing dialog box visually annoying, it turns what should be a super-fast process into one that takes a ridiculous amount of time. The end result is that users think they have a slow machine—"it took over 12 seconds to expand 25 tiny little archives!"—when what they really have is a horrendously slow GUI interface to a super fast task.
Just how fast is the task, if the GUI doesn't get in the way? Thanks to the Unix core of macOS, we can answer that question using Terminal, the geeky front-end to the Unix core. The Unix command to expand .gz archives is gzip; so to expand all the .gz files in a folder (and keep the originals), you'd use this command in Terminal:
gzip -d -k *.gz
If you try this, you'll find out it's nearly instantaneous—press Return, and the files are expanded. Unix actually gives us a way to see exactly how fast it is, via the time command:
$ time gzip -d -k *.gz
real 0m0.013s
user 0m0.002s
sys 0m0.005s
This was for a set of 24 .gz archive files (on a solid state drive), and the real line in the output shows exactly how long it took to expand them all: 0.013 seconds. By comparison, I made a screen recording (with an onscreen stopwatch for timing) of Finder expanding the same 24 files; it took 12.8 seconds for all the dialog dancing to end. Think about that…
Expand 24 .gz files
Finder: 12.8 seconds
Terminal: .013 seconds
Terminal is 984.6x faster than Finder
To put those results another way, if expansion time is linear, gzip could expand 23,631 files in the time Finder takes to expand 24 files. That's nuts!
(You can watch this video for a visual comparison of expanding the same set of files in Finder and Terminal.)
So it's not the computer that's slow, it's the GUI interface to the computer that (in this particular use case) is incredibly, horrendously slow. And there's no need for it—the separate individual progress bars, appearing and vanishing in under a second each, provide no useful feedback to the user. They just slow down the task.
Finder (née Archive Utility) should just execute the task without any visual feedback (though it should pop up a window if there are exceptions). If visual feedback is really required, a window with a single progress bar for the entire task would be OK, but would still slow operations down.
This is a great example of how an everyday task can make you think you have a slow computer, when what you really have is a fast computer with a slow interface element. Given how often we all deal with compressed files, it'd be nice to see Apple clean up this mess. Until they do, however, you can harness the power of Unix—even while in Finder—to speed up the task. Here's one way to do just that.
