The crux of the switch

It’s almost hard to imagine Mac OS X without a good application switcher. But previous to OS X 10.3, that was just the case. Back in 2003, I summarized why the previous application switcher was so poor:

To switch the active application in 10.2, you hit Command-Tab and a highlighted dock icon told you which application was selected. It worked, but it had problems. The biggest of which occurred when open applications were separated by several unopened applications on the dock. When this happened, the highlight skipped across these unopened applications in a seemingly unpredictable manner because almost no one could remember exactly which applications were open and which applications where closed.

A Better Switcher

In 2001, a small software startup named Proteron announced LiteSwitch X, an OS X update to its popular OS 9 keyboard application switcher. LiteSwitch was essentially a Mac implementation of the Alt-Tab switcher found in Windows, but with an additional slew of features including drag and drop support, closing multiple applications and windows layering control. I was unsatisfied with the 10.2 application switcher and started using LiteSwitch X soon after buying my first Mac.


Apple caught up to Proteron in OS X 10.3 and introduced its own application switcher albeit with significantly less features than LiteSwitch X. Apple’s switcher has remained relatively unchanged since its original implementation.

OS X 10.6 Application Switcher

Hit Command-Tab and you switch from the current app to the next most recently used app. If you hold Command, all running apps are displayed, and you can continue hitting tab to switch to another app. You can additionally hold down Shift and cycle in the opposite direction, and use the H and Q keys to hide and quit applications.

Apple slightly improved the switcher with 10.5, introducing drag and drop support and then again with 10.6, allowing you to trigger Exposé and show all windows of the selected application by hitting the up or down key.

Blinded by the Lite

Version 1.1 of LiteSwitch X introduced a preference for sending the reopen event to applications upon switching to them. This meant that LiteSwitch would force OS X to reopen the window if it had been closed, or restore the window if it had been minimized to the Dock. I enabled this preference soon after I started using LiteSwitch as it felt like the most natural way to switch to an application. With every OS X update, LiteSwitch X was one of the first add-ons that I installed. So when I switched to an application, I expected to it to be visible — the only exception being if it was a document-based application and there were no open documents.

In early 2009, I noticed that the Proteron website was down (The Wayback Machine records July 24, 2008 as the last date the website was reachable), and over the past year I was concerned about continuing to use software that was no longer supported. So near the end of December I begrudgingly tried to use the built-in OS X switcher.

Having been blinded by LiteSwitch for so many years, I was completely set back that the OS X switcher didn’t reopen closed or minimized application windows. For example, say iTunes was open but the main app window was closed. If I switched to iTunes, no window would appear. Switching to Finder, Mail, Address Book, Safari, Tweetie, Adium and other apps also didn’t reopen application windows.

Shortcut Madness

Given that switching didn’t reopen application windows, I expected a common keyboard shortcut for accomplishing this. Unfortunately, shortcuts only complicated the situation. To show the iTunes main window, I needed to hit the keyboard shortcut for opening the window (Option-Command-1 in the case of iTunes) or click on the iTunes Dock icon. There’s no unified keyboard shortcut for reopening the main window - even among applications made by Apple. Here are the keyboard shortcuts for the apps I listed above:

  • iTunes: Option-Command-1
  • Finder: Command-N
  • Mail: Command-1
  • Address Book: Command-0
  • Safari: Command-N
  • Tweetie: Command-0
  • Adium: Command-/

These are just the apps that have a shortcut. Many, like Evernote, don’t even have one.

After tweeting about the lack of a standard shortcut for reopening main windows, Martin Polley pointed out that the OS X application switcher actually can reopen windows with some additional shortcut trickery.

It goes like this: hit Command-Tab to switch as you would normally, then when the app you want to switch to/reopen is selected, hit Option while continuing to hold Command. Then release Command before you release Option. Go ahead and try it now. When you first start using it, it’s quite painful after the simplicity of Command-Tab, but it does get slightly easier over time.

Personally, I love controlling OS X via keyboard, and most of the time I welcome consistent and standard keyboard shortcuts for commands. However, I believe that adding a shortcut for reopening windows is the wrong solution because it defies traditional keyboard shortcut expectations. For nearly every keyboard shortcut I use in OS X, there is a perceived before state and an expected after state. For example, if I’m browsing a site in Safari and I want to jump to the search input, I hit Command-Option-F. In the before state, I perceive that the webpage has focus. The expected after state is that the search input will have focus. In the case of the OS X reopen shortcut, the before state is that the window is closed or minimized. The expected after state is that OS X will bring the selected application forward and reopen or restore the window. The issue is that it’s very difficult, and sometimes impossible, to know if the window is actually closed or minimized. So for the shortcut to be truly effective, the user needs to remember which windows are open and which windows are closed or minimized. This is unrealistic at best.

Switching 101

Out of the box, the Mac offers three key ways to switch applications, and each of them behaves differently.

  • The Dock. Click the application icon in the Dock to switch to the application and bring all of its windows, including closed application windows or individual minimized windows (if the app has only one window and it’s minimized), to the front. Clicking on an application’s Dock icon to switch to that app is one of the first skills that a new Mac user will learn. So it makes sense that doing this brings that application’s windows to the front.
  • Selecting the Window and Exposé (now part of Mission Control). Click within an window to switch to the application and bring the selected, but not all of its application windows, to the front. Exposé is a different way to visualize windows but the same behavior applies. This is even more straightforward that clicking on a Dock icon; clicking on a window brings that window forward. For the new user, it seems okay that only a single application window comes to the front because the user clicked a single window. (As a historical note, in OS 9, clicking within a window actually brought all the application’s windows to the front.)
  • Command-Tab. Hit Command-Tab and you switch from the current app to the next most recently used app and bring its open windows to the front. Let’s consider the new Mac user again. Clicking on an application’s Dock icon brought that app’s windows to the front, but using Command-Tab to switch to an app — which looks identical to the app icon in the Dock — only brings open windows to the front. It’s easy to assume that this isn’t going to make a lot of sense to the new user.

I believe that Command-Tab is the only way to switch applications without affecting windows because when Apple implemented the switcher in OS X 10.3, someone decided that it was the one true application switcher. And a true application switcher shouldn’t affect windows; a true application switcher only switches the application.

This is where Apple misstepped. Beyond being inconsistent with its closest switcher sibling the Dock, it doesn’t provide perhaps the most important thing that most users need upon switching: to see an application window.

Applications and Windows and Documents

Every application has at least one window. Some applications are document-based, meaning they allow the user to operate on multiple items at the same time. Mail, TextMate and Photoshop are all examples of document-based applications. Typically, document-based applications have one window per open document and often have multiple windows open at once. Other applications are non-document based; in these apps the user can only operate on one item at a time. As of this writing, iTunes, iCal and Address Book are all examples of non-document based applications. Typically, non-document based applications only have one window. For all practical purposes, that window is the application.

In the case of non-document based applications, the argument for always showing a window upon switching is easier. If you want to use iTunes, there’s practically nothing you can do without the application window. The same is true for iCal, Address Book and many other single window apps.

It’s a little trickier for document based applications. If the application has one document open, it makes sense to show that window — even if its minimized — because there’s a damn good chance that they’ll want to see that window. (People who keep their Dock hidden: have you ever switched to a document-based application and thought nothing was open because you didn’t see a window, later only to discover that you had a window minimized in the Dock?) If the application has two documents open, it makes sense to show the last document (window) the user interacted with.

Here’s the tricky part: what if a document-based application doesn’t have any documents open? Current apps handle this in different ways: some do nothing, some open a new untitled document automatically, some make it a user preference. Personally, I prefer apps to do nothing and not open any new windows, but ultimately I believe the window opening behavior should be based on the app. This, then, is the only exception to showing a window upon switching: if a document-based application doesn’t have any documents open, the developer should choose the window opening behavior and in some cases, allow the user to choose in the application preferences.

The Crux of the Switch

Switching should reopen closed and minimized application windows. It’s consistent with other ways to switch and therefore easy to understand. But most importantly, it’s what the user needs to use the app in most cases.

Given that Apple has released three versions of OS X since introducing the application switcher, I’m fairly certain that they would be extremely hard pressed to change its behavior at this point. The good news is that Ammon Skidmore, previously of Proteron, is keeping LiteSwitch alive, and it continues to work in OS 10.9.

The Crux of the Switch was originally published in January 2010 on my tumblelog, also unraveled.


  1. All good points.

    It sounds like there are only two issues here - and they fix each other (sort of) one could be fixed without adjusting switching, but the switching solution would remove the need for the other fix.

    Basically either have OSX restore/open new window on apps it switches to OR have a unified OS keyboard shortcut to do the same.

    The more likely solution is the former, but it would be nice to have the latter anyhow (or at least a stable developer convention).

    I’m actually surprised that this sort of thing slipped by Apple - they’re usually quite hot on this sort of thing - but the switching app has always been a little bit of a red-headed stepchild.

    Why that is, I’m not sure - but I DO find myself switching a LOT less in OSX due to the way the windowing works. From observation of other peoples habits that seems common - Windows users alt-tab a LOT more than OSX users.

    An interesting interaction difference…

  2. You forgot about Command-Tab’s little brother, Command-` (for switching between documents within an application).

    Having previously been a mostly Linux and Windows user, the (imvho) artificial distinction between windows and applications is a major pain point - I would much rather have a single keystroke that lets me switch between any two documents / windows, regardless of which applications they’re part of.

  3. I agree that it would make sense to open the main window in apps that aren’t document-based. When it cones to document-based apps, however, I want my windows to stay minimized. I have a reason for minimizing them. In Safari, for instance, I like to minimize the pages I shall read later. I don’t want them to jump open.

    I also think it’s nice that I can bring up invidiual windows from different apps without bringing up all the windows. This is often usuful.

    I usually switch applications with the key combination but I have my Dock configured so that when I click an app it hides the others. I don’t remember the terminal command but I Finder this useful for cutting the clutter.

  4. I switch to iTunes to pause by pressing space when I have multiple apps open that listen to media keys. I switch to Text Edit to open a new document (cmd-N). I switch to Preview to have a look at the image that is in my clipboard (also cmd-N). I often switch to apps to bring up their prefs (cmd-,). All actions that would take longer and annoy me if the app brought a minimized window up when I switched to it.

    Also, how would the app magically know *which* window I would want to un-minimize? If it chooses the latest (or any other algorithm), and the choice was wrong, I’ll have to take two extra actions (minimize and un-minimize) every time I switch to that app.

    Instead, we have Exposé for switching to specific windows, which lets us retain cmd-tab for application switching.

    What you are describing is *your* ideal work flow. You admit so yourself, by installing LiteSwitch with every new system. What you are describing is not *the ideal work flow for everyone* (which you assume, possibly because it feels so natural to you), but yours.

  5. @Peter: I didn’t mention command-` because it’s irrelevant in the context of switching applications.

    @Joachim: Similarly, what you describe in the first paragraph above is your ideal work flow — a very keyboard driven one, which very not typical for most users. I would strongly contend that most users are point and click driven, which is why I believe showing the app window — something that they can point and click at — is so important.

    I think it would make sense if the switcher reopened the main application window, or the case of document based applications the last used window. When I say “showing a window,” I’m referring to the main application window for non-document based applications.

    I understand why a lot people like Expose. It’s a great window visualization tool that allows point and click driven users to see all open windows and switch the active window and/or application. But 9 out of 10 times the app I want to switch to only has one window open, so I find it less efficient than command-tab. In the 10th case, I can then use command-` to switch to the desired window.

  6. nice article, keep the posts coming

  7. I’ll have to go back and read all your previous posts now.

Comments are closed for this entry

Please send your feedback via Twitter to @jmk.