On Twitter, I've shared my distaste for Catalyst apps, as many of them just don't "feel" right to a long-term Mac user. I know that's vague, but today, the vagueness ends, thanks to a deep dive into Apple's recently-released Developer app for macOS. No, the deep dive isn't this blog post you're reading now, but rather one by Martin Pilkington.
He has written a great analysis of the numerous issues with the Developer app. (And importantly, he filed bugs on everything he listed.)
Many of the issues aren't specific to Catalyst, but reflect poor attention to the details that make a Mac app look and act as a Mac app should. Here are but a few of the examples from Martin's analysis:
The focus ring on the search field has square corners • The search field focus ring does not go away if you click elsewhere in the app • Doesn't show window title when toolbar is hidden • Content size is too small • Can't collapse groups in the sidebar • Find toolbar does not share search string across OS
I strongly encourage you to read Martin's article, as it puts into words just why I find many Catalyst apps so annoying to use. In addition, I'm going to provide a couple more examples—using the same Developer app—showing just how non-Mac-like a Catalyst app can be…
My new iMac runs Mojave; my old iMac never moved off High Sierra, which I felt was a fine version of macOS. Now that I have no choice but to use Mojave full time (I have it on my laptop for work purposes), I'm finding some annoying changes. Amongst those annoyances, this one is—by far—the most annoying…
That's a set of messages in Mail, as viewed in Classic View mode (using San Francisco Display at 15pt on both Macs).
Somewhere in Apple, someone thought it'd be a great idea to reduce the line spacing in Mail—only when using Classic View, which is my forever-preferred view. Maybe they're doing this to force us to upgrade to the modern view?
And obviously, it would be, because there is no month 13. But if you're unlucky enough to be a Mac user in the month of December, 2017, then you'll probably be seeing a lot of "Month 13 is out of bounds" messages in your Console. And by 'a lot,' I mean an exceedingly excessive never-ending stream of spewage…
Thousands and thousands and thousands of them—I'm getting anywhere from two to 20 per second, continuously. Ugh.
This just started happening this morning, and it's happening on all my Macs. I found one Apple developer forum thread that talks about the problem, and user Helge seems to point to a bug in mdworker…
I've recently—begrudgingly, forcibly—migrated from iPhoto to Photos. My iPhone 8 Plus was the main impetus, as Photos supports its new movie and image formats, as well as providing some additional editing features that I can't get in iPhoto. But in my limited time with the new app, my general conclusion is that Photos is not designed for someone who likes to actively manage their photo collection.
I may have more to say about this in a future post, but for now, consider this style of Smart Playlist that I used a lot in iPhoto…
This structure effectively creates an "and and or" logic, where you can have all conditions must be true at the top, yet have an "or" on the keyword: This playlist finds media that have the keyword Midnight or Moonlight (our cats), and are videos.
You simply cannot build this structure in Photos, because the Keyword field is a tokenized pop-up; you can only select one value. If I list the keywords as separate criteria, I wind up with a Smart Playlist that only finds videos with both Moonlight and Midnight. That's not what I want.
This structure is useful whenever you have multiple individual things—kids, lets say—and you want a smart playlist that will find any of your children and any other criteria, like year or camera or whatever.
My first thought at a workaround was to create a Smart Playlist called The Cats, which simply had the two Keywords as "or" criteria. I'd then create a second Smart Playlist that had one criteria set to "Playlist is The Cats" and the other set to find only videos. But Photos won't let you use a Smart Playlist as a criteria (neither will iPhoto, for that matter).
After some fiddling, I came up with an ugly but functional solution: I have to use an extra keyword. Now, any time I add photos of either cat, I have to set two keywords: One with the cat's name, and the other is The Cats. With two keywords on every cat photo, I can use this Smart Playlist to make my "video of either or both cats" Smart Playlist:
I'll have to do the same for our children; each picture of Erica or Kylie will also get a The Kids keyword. It really shouldn't be this hard; Smart Playlists should work as do Finder searches…
I know that's a shocking headline, but that certainly seems to what they're saying for a certain group of users (red emphasis added):
By default, your System Photo Library is stored in the Pictures folder on your Mac, but you can move it to another location on your Mac or store it on an external storage device. WARNING: If a Photos library is located on an external drive, don’t back up the drive using Time Machine. The permissions for your Photos library may conflict with those for the Time Machine backup
Jan 23 2018 update: Thanks to reader Brian for commenting below that Apple has updated this page with much clearer wording. It now reads (emphasis added):
If a Photos library is located on an external drive, don’t use Time Machine to store a backup on that external drive. The permissions for your Photos library may conflict with those for the Time Machine backup.
That just means you shouldn't use the same external drive for both your Photos library and as a destination drive in Time Machine. This makes much more sense; continue reading only if you care about my feelings on the original incorrect wording.
Another post thanks to Many Tricks' Peter Maurer; this particular bug bit me last night—I spent 30 minutes trying to figure out why a compiled AppleScript with a droplet wasn't working. I never did get it, so I emailed Peter, and he pointed me to these tweets from a while back…
…which means the app won't launch. You have to "chmod +x applet" manually to make it work.
While playing around with Messages this morning, I noticed that it ships with a feature that, if used, throws an error. Steps to reproduce:
Open Messages' preferences.
Set the Applescript handler pop-up to any of the listed scripts:
Close preferences, and try to send a message to anyone.
Revel in the brokenness.
I especially like the execution error: No error message…it's that rare non-error that tosses up an error dialog!
In any event, I think it's shameful that Apple ships the app with a feature—plainly obvious in prefs—that breaks when used. Yes, I know AppleScript is probably dying, but that doesn't excuse shipping the app with a clearly-broken feature; if it doesn't work, just remove it. Apparently this has been an issue since Yosemite's release in October of 2014!
With all that said, fixing this is incredibly easy—it took me about 30 seconds of "work" to find and fix the problem. If you'd like to use the bundled AppleScripts in Messages—either as is, or in some modified form—here's what you need to do
Over the weekend, I wrote about my totally useless search in Mail. I got so frustrated by my inability to search in Mail that I decided it was time to for a complete rebuild. I exported all my locally-saved mail, deleted my accounts, quit Mail, trashed its prefs and data files, rebooted, then rebuild it mailbox by mailbox, account by account.
I started with my iCloud account, which I barely use for anything—it has a total of seven messages in the inbox (four of which are iTunes Store receipts), and only 121 sent messages. As a test, I searched for Linea, an excellent drawing app that I had recently purchased. No matches.
At that point, I decided to quit Mail and force Spotlight to rebuild its index overnight. In Terminal, sudo mdutil -i on / will do just that (and take many hours). Today, opened Mail, and search was still dead. Argh! (I had also tried this suggested fix, but it made no difference.)
But doing some random testing today, I discovered a fix! It's a weird fix, but it seems to work:
If I move all the messages from an inbox or local storage folder into a different local storage folder, they'll be indexed and findable. I can then move them back into the inbox or source folder, and they remain findable. Even more important, newly-added messages seem to be properly indexed, in both the inboxes and the local storage folders.
This doesn't make any sense to me, as any one of my recent actions—rebuilding mailbox indexes, reimporting, and redoing the entire Spotlight index—should have been enough to force a rebuild. But for whatever reason, only manually moving the messages seems to force a rebuild.
Now pardon me while I go back to manually dragging a quarter-million email messages around…
For the last couple macOS releases, I've had nothing but trouble searching in Mail. Note that I didn't write "trouble searching mail," but rather, "trouble searching in Mail." For example, today I needed to find an email from my business partner Peter about a hidden pref in Butler. (I was hoping this pref could help a user who was having problems with the pasteboard in a certain app.)
Based on a document on my hard drive, I knew the name of the default was Pasteboard Normalization Interval, but I couldn't remember the syntax of the defaults write command to set its value. So I searched in Mail…
So clearly, no emails in my database contain the words I'm looking for, right? Here's the exact same search, run in Spotlight:
Not one but two email messages match my search, and provided the needed syntax for the command.
Wait, I know what you're thinking: "Ahh, look, it's in quotes!" Doesn't matter; searching Mail for "Pasteboard Normalization Interval" still results in zero matches. Searching on even one word of the phrase, like Normalization, also finds no matches.
Again, I know what you're thinking: "Oh, I bet the Mail index is screwed up." Nope; even after rebuilding the index on all 250,000+ messages in my database, no matches are found. (And yes, I let the index complete its rebuild, which took hours.)
I've heard from others that search in Mail works for them. But it's a no go for me, and I know, for others. So something's wrong, but I don't know exactly what it is, nor how to fix it.
So for now, I have to rely on Spotlight to search Mail…or a third-party app, but more on that in a bit.
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
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.