A Lexical Path Toward a Paradigm

I am still not in love with the name “Stage Manager” because it mixes metaphors and is easily confused with “Center Stage“. My opinion is evidenced by the many gaffs I’ve already heard on various Apple-centric podcasts. That said, the mixed metaphor was just one of my issues with Stage Manager’s naming. The other and much more egregious problem is how the main components that make up Stage Manager simply don’t have names. This is nothing new to iPadOS. Again, here’s what I wrote in January:

What is the noun for the thing that is being split? Is it a view? Maybe it’s a window? Okay, so how do I get to that Safari “window”? Maybe it’s on that “screen”, but that’s also not really a term Apple uses as far as I am aware.

Can you imagine trying to describe macOS without nouns like “window”, “desktop”, and “dock”? Names don’t just make describing and documenting an interface much easier, they also inform relationships. “Windows live on the desktop and can be minimized into the dock“. To that end and for the purposes of this post, here are the nouns I will be using when writing about Stage Manager:

  • stage — a main area of a screen
  • wing — where other sets live when they are not on a stage
  • set — a window or collection of windows to be displayed on a stage simultaneously
  • stack — a collection of sets that belong to a single application in the wing
  • stage manager — the mechanism that manages which of the sets are on stage verses those that are waiting in the wings

I am sure some will quibble with my choice of names, and while I wouldn’t staunchly defend them, I would strongly argue that, good or bad, their mere existence drastically improves Stage Manager. Using that lexicon, I can answer my three questions.

  • Where am I now? — At this window in this set on this stage
  • Where is the thing I want? — In a window in the second set in the wing
  • How do I get there? — Bring the second set in the wing on stage and select the window

These nouns also enforce a paradigm, which iPadOS has desperately needed since it first introduced multitasking. Here’s what I wrote in March of 2021:

iPadOS is descended from iOS and thus shares much of its user interface paradigm. iPadOS contains screens, each of which contain apps and other things. Also like iOS, the iPadOS App Switcher is effectively a screen switcher in that it still cycles between screens. The problem is the iOS paradigm completely breaks down as soon as the one-to-one relationship between screens and apps is lost. Enter iPadOS multitasking, where one screen can contain multiple apps and a single app can live across multiple screens. An iOS-style screen switcher can’t navigate to a given app when screens can have multiple apps. iPadOS also supports command-tab, but a macOS-style app switcher can’t show an entire app that is divided across multiple screens.

Stage Manager introduces a hierarchy that I hope Apple leans into. Windows belong to sets and sets belong to stages. Given this hierarchy, I don’t think command+tab should switch between apps because, just like with existing multitasking, an app switcher can’t work when an app is divided across multiple stages. Instead, I think command+tab should switch between sets and command+` should switch between windows in the set that is currently on stage1,2.

On iPadOS, I would go even further to say that stages and sets should exist even when Stage Manager itself isn’t active, because the paradigm still works. A set would still be a collection of windows and a stage would still be the main area of a screen. Command+tab would still switch between sets and command+` would still switch between windows currently on stage. The only differences when using classic iPadOS multitasking would be:

  1. Most sets would have just one window, in which case command+` wouldn’t apply
  2. Multiple windows in a set would be split instead of overlapping
  3. There would be no wings

On macOS, my proposed command+tab and command+` behavior would be limited to Stage Manager. That sounds confusing, but I don’t think it would be cognitively problematic given Stage Manager is an alternative windowing mode that is completely separate from macOS’s existing windowing UX.

Despite my criticism, I am actually very excited for Stage Manager. This simple exercise of naming its various components makes me optimistic that Apple is close to finally having a sensible multitasking paradigm on iPadOS. That said, my optimism is still tempered by the fact that I made up these names specifically because Apple didn’t.

Update: The consensus feedback I got is that “wing” is a better name for the dingus on the left than “deck” because “wing” works with Apple’s stage metaphor. I had originally used “wing” in an earlier draft for that very reason, but thought it was too obscure whereas most people know what “on deck” means. I decided to change it back to “wing” for two reasons:

  1. My sense that it was too obscure was off to say the least, especially given the phrase “waiting in the wings” is roughly as common of a term as “on deck”.
  2. The biggest point of this post is that names matter, in part because they inform relationships. Often those relationships are best informed when names are part of a consistent metaphor. Computers have “files” and “folders” because the real world has files and folders, and so Stage Manger has “wings” because actual stages have wings.

Update 2: Added the noun “stack” and updated the definition of “set”. You can read more about why here.


  1. Alternatively, you could maybe use command+caps for cycling through stages. Even so, I still think command+tab and command+` should only cycle through apps and windows in the current set on stage given Stage Manager is supposed to be a way to focus on specific tasks. The last thing I’d want is to be taken completely out of that task by some errant keystroke. ↩︎

  2. Mission Control uses control+arrow keys, but I don’t like using arrow keys for context switching. The brilliance of command+tab and command+` is that they only involve the left hand, leaving the right hand free to operate the trackpad, mouse, or touchscreen. ↩︎