A Step Back

Let’s try something together. What do these things all have in common?

• Photos

• Music

• News

• Podcasts

• TV

• Stocks

• Mac App Store

You thought they were all going to be iOS apps until I surprised you with that last one, right? These are all MacOS apps, yes, but they are not all of the same kind. Many of them are media apps, but it’s hard to think of Stocks, News, or the App Store in the same category.

Three of them — News, Podcasts, and Stocks — are Catalyst apps that were ported from their iOS equivalents. Two — Music and TV — are standard MacOS apps, but Music is built on a rickety base of code that dates back to the Clinton administration. Photos, meanwhile, is a Frankenstein’s monster of an app. It was originally built on a framework called UXKit, which appears to be some kind of cross-platform precursor to Catalyst. At some point in the last five years, obvious traces of UXKit were stripped from MacOS; alas, Photos still feels like it has one foot in iOS and the other in the Mac. The redesigned App Store introduced with Mojave is similarly confused about which platform it is supposed to belong to, but I have no clue what framework it’s built on.

The thing common to all of these apps is this — and you have to imagine that I am writing the next word with a similar tone to that which you might use in reference to a dog turd stuck to someone else’s gum stuck to the bottom of your shoe — button:

This back button manifests in different ways in the apps I named above. Sometimes, it appears in the main toolbar alongside the traffic light window buttons, invisible until something happens in the app to cause it to show up. At other times — as in Music, TV, and Podcasts — the app will draw a toolbar containing only that button, usually very small and floating somewhere off to the lefthand side.

In no circumstance will it indicate where it will take you back to. Not on the button, not if you click and hold, not in a hover-activated tooltip — you get no sense of what that button will do, other than taking you back somewhere, whatever “back” and “somewhere” mean. If you click it immediately after performing an action, you probably have a good sense of what will happen. But if you search something in Music, click on a playlist in the search results, click on an artist in the playlist, play an album, and then go do another task for half an hour before returning, will you remember where that back button ought to take you? More to the point, will it take you where you might expect?

This back button does not behave like the one in any web browser which, I expect, is the back button any user is most familiar with. Trackpad gestures don’t work with it, so you cannot peek at the previous item. There are ways in which these apps try to meet in the middle ground between a standard Mac app and a web app — Apple Music is basically just a web view within Music, and you feel every aching moment of that, so the back button kind of works. Yet, the moment you get into the more Mac-like local music library section the app, the back button’s intent disintegrates. Here’s an example:

1. Click on the Albums view of the local library.¹

2. Click on any artist name in that view. It’s grey text that doesn’t look clickable but, trust me, it will take you to a list of albums in your library from that artist.

3. A new secondary sidebar will appear containing a list of all artists in your library. Click on another artist’s name.

4. Click the back button.

This should, theoretically, load the most recent view — it should return you to the list of albums by the artist in step two. That’s what the back button in Finder’s column view does. But it doesn’t; it goes all the way back to your entire list of albums.

Is this a problem with Music, maybe? It’s janky as hell: it is inexplicably worse to use than iTunes despite losing the added-on cruft of TV shows, movies, iOS device management, and so on. It’s also built on decades-old code. What about something more modern — a direct iOS port, for example? What about News?

1. From the Today view, click on any story.

2. Swipe from right to left on your trackpad to advance to the next story.

3. Click the back button.

Step two feels pretty much the same as something you might do in a web browser, yet the back button returns you to the Today view’s “home page”. Surprise!

Maybe you are getting the impression that, in these apps, the back button is a way of returning to the top level of a section. So let’s test that in the Mac App Store.

1. From any of the store sections, click on an app from a well-known developer. I went with OmniGraffle from the Omni Group.

2. Click on the developer’s name to pull up all of the apps they make, then pick another app. In this case, I picked OmniFocus.

3. Click the back button.

Think maybe it will take you back to the top level of the store, or maybe to that first app’s page? Nope: it behaves like a standard back button and takes you to the list of developer’s apps that was previously open.

It does not even appear in all of the instances you might expect. For example, if you open an app’s page from the Discover screen of the Mac App Store, the back button appears. However, if you open one of the “editorial” stories, no back button appears at all. There is only a “Done” button that, bizarrely, sits in the upper-right corner of the App Store app instead of the back button’s upper-left positioning, requiring that you hunt for it as you vaguely recall that editorial items are somehow special or different.

The more common apps that have long featured back and forward buttons do not function in these peculiar ways. Web browsers do not; Finder doesn’t; neither does System Preferences. And, as I was writing this article, I was worried that it would be made obsolete by the forthcoming release of MacOS Big Sur, but everything is pretty much identical as of the latest beta.² If the back buttons in the apps listed at the top of this post do not conform to the system standard in any way, the obvious question is something like: “why do these apps have a back button at all?”

In every instance, it seems to be a catch-all attempt to solve complex UI design problems. In Catalyst apps, it kind of works like the iOS system back button. In the App Store and in Music, it is a way to display web-based pages without having to implement a hierarchical navigation structure. In Photos, I suppose it is a way to reduce the amount of toolbars and buttons onscreen compared to iPhoto, and to make it conform closer to its iOS counterpart.

For completeness, I should note that iPhoto used back buttons in a handful of views. You can see one in the upper-left of the screenshot in this tutorial, but you will notice that it is labelled. When a user clicks it, they know they will be returning to the “All Events” view. The floating carets of Apple’s post-iOS 7 design language replaced contained back buttons — one of the more upsetting casualties of that redesign, I think — but MacOS still has buttons. If these back buttons were labelled, it would make them better.

I return, however, to my view from two paragraphs ago. I see these back buttons as a sort of cop-out — an easy way of covering for a lack of deeper consideration. You can see this most clearly in iTunes running on Mojave, in which there are two very different implementations of every view: the Apple Music way, and the local library way. If you open an album from the Recently Added view, it expands to reveal the track list below. If you open an album from Apple Music, you get sent to a new page, presumably because it is not possible to implement the local library style in a way that is performative or works across different platforms. It reveals the web-based underpinnings of Apple Music, it is slow, and it necessitates a back button.

In Catalina’s Music app, the two different implementations of an album view were dropped in favour of the Apple Music style. Now, it always opens an album in a separate view. As in every one of the apps I listed above, this decision makes Music feel like a semi-native wrapper around a collection of webpages, even when many parts of the app are still entirely native.

I do not think it is always wrong for an app to have a back button; it is a mechanism that works just fine in a web browser and in file managers. But I think that this new breed of apps that try to bridge the gap between MacOS and iOS use this specific implementation of the back button as a crutch. It is an inelegant way of dealing with inelegant and unique design problems. Its pervasion is a big flashing CAUTION sign that Apple’s Mac apps are not being lavished with the design attention they once were and still deserve. What bothers me more than what the button is is what it represents: it is, uncharacteristically for Apple, lazy.