Ron Amedeo over at Ars Technica put together an excellent overview of Google’s RCS, and why it’s not the same as standard RCS. Here’s what Ron had to say:

Google tried to glom features onto the aging RCS spec, but if you consider those part of the RCS sales pitch, which Google does, now it’s more like you selling “Google’s proprietary fork of RCS.” Google would really like it if Apple built its proprietary RCS fork into iMessage.

So the pitch for Apple to adopt RCS isn’t just this public-good nonsense about making texts with Android users better; it’s also about running Apple’s messages through Google servers. Google profits in both server fees and data acquisition.

Google pitches RCS as “open like Linux”, but it’s really more “open like Android”. There is an open source component for sure, but make no mistake, the RCS being sold is the one Google controls. Never mind that Apple and Google are bitter rivals, why in the world would a company staking its brand on privacy further a relationship with one helplessly addicted to user data?

Nightly Time Machine is a small side project I have been working on for a few weeks to make Time Machine more usable with my laptop.

From my Github:

At its best, Time Machine is “set it and forget it” in that you should never really have to think about it until a backup is needed or a backup disk needs to be replaced. Time Machine by itself is only at its best on desktops. On laptops, where external drives are frequently disconnected, Time Machine becomes a hassle at best and a risk to data at worst. With Nightly Time Machine, Time Machine is “set it and forget it” on laptops.

Apple did something clever with how stacked windows in the strip are cycled. When clicking on a stack of windows in the strip, Stage Manager prioritizes keeping the outgoing window on top of the stack.

Assuming you have window A on the stage, and windows B, C, D are in the stack in that order. Now say you want to switch to window C.

If Stage Manager merely cycled the stack in order…

1. The first click would shuffle window A to the bottom and bring window B to the stage. The stack order at this point with B on stage would be C, D, and A.
2. The second and final click would put window B on the bottom behind A and move window C to the stage. The final stack order with C on stage would be D, A, and B.

The problem with merely cycling in order is that window A is almost always buried at the bottom or in the middle of the stack despite being the one most recently used.

What happens in macOS 13 beta 4¹…

1. The first click moves A to the top of the stack and brings window B to the stage. The stack order at this point with B on stage is A, C, and D,

2. The second and final click leaves A at the top of the stack, moves B behind it and brings C to the stage. The final stack order with window C on stage is A, B, D.

The beauty of this is how the most recently active window, A in this case, remains on top of the stack. Being on top makes window A the easiest to bring forward, which makes sense because users are more likely to go back to the window they’ve most recently used.

Command+`cycling has also been updated, but curiously not in the same way. In Beta 3, command+` cycling seemed nonsensical to me. Beta 4 command+` now cycles through windows in the order of their stack, albeit backwards from how I expected. I expected command+` would put the current window on the bottom of the stack and replace it with the one on top. In beta 4, it puts the current window on top of the stack and replaces it with the one on the bottom. That said, I am now convinced that merely cycling through stacked windows in order is not sufficient, and that the commmand+` cycling behavior should mirror the one that happens when a stack is clicked².

The cycling behavior when clicking a stack is exactly the kind of consideration and detail I expect from Apple. It’s great to see it in the betas.

Apple giveth and Apple taketh away. In macOS 13 developer beta 3, I was elated to see that Apple had named Stage Manager’s dingus on the left a “strip”. Imagine my surprise and disappointment to find that name erased and replaced with “Recent Apps”. I have a few quibbles with this change. First of all, it’s not really a name for the dingus, it’s a description of what the dingus holds. Second, that description isn’t even accurate. The dingus doesn’t hold apps, it holds sets and stacks of windows and while stacks are organized by app, sets aren’t because they can involve multiple apps. Apple in theory could call it “Recent Sets” and say all windows, even standalone ones, belong to a set in Stage Manager, but they can’t. You know why? Because Apple doesn’t have a name for those UX mechanisms either! “Sets” and “stacks” are terms I invented just so that I can coherently write about Stage Manager.

Even without formal names for the UX components in Stage Manager, I think “Recent Windows” would be way more accurate than “Recent Apps”, but even then I would argue that merely describing the contents of the dingus is no substitute for actually naming it. Imagine if the dock didn’t have a name and instead was referred to as “Favorite Apps”. It wouldn’t make sense because the dock also contains open apps, stacks, and the trash. Furthermore, the type of stuff that goes into the dock is free to change because the dock isn’t defined by its contents. The dock didn’t need to be renamed when stacks came with Mac OS 10.5.

Seeing the lefthand dingus be given a name in one beta only to have that name taken away in the next one is particularly worrisome to me. It suggests a fundamental lack of consensus within Apple’s software division. I’ve complained about conceptual incompleteness in iPadOS’s multitasking before. Stage Manager, as useful as it seems, has me worried that this conceptual incompleteness is starting to bleed into macOS.

John Gruber recently took umbrage with Wirecutter’s pick for best laptop. Here’s what he wrote:

My longstanding complaint about The Wirecutter is that they institutionally fetishize price over quality. That makes it all the more baffling that their recommended “Best Laptop” — not best Windows laptop, but best laptop, full stop — is a Dell XPS 13 that costs $1,340 but is slower and gets worse battery life (and has a lower-resolution display) than their “best Mac laptop”, the $1,000 M1 MacBook Air.

Not only do I agree with John’s objection about pricing, I’ll add my own about terminology. In an article titled “The Best Laptops”, Wirecutter confusingly refers to the “best in show” category as “best ultrabook“, and describe “ultrabook” as follows:

[Ultrabooks] have great keyboards, screens, and battery life, they offer enough power to do everything most people need a computer for, and they’re thin, light, and portable. You should expect to pay between $900 and $1,300 for a great Windows ultrabook that will last you three to four years.

Take out the word “Windows” and what the authors describe is the category of laptop defined by the MacBook Air. In that sense, “ultrabook” really means “off-brand MacBook Air”. Naming the category “best ultrabook” instead of “best laptop” feels like a deliberate cop-out to justify excluding Apple’s MacBooks.

Wirecutter’s exclusion of MacBooks from a category that is effectively “best laptop” is the latest bit of evidence in a recent trend I’ve noticed wherein reviewers have inexplicably stopped comparing Wintel laptops to Apple’s MacBooks. Compare Ars Technica’s review of the Surface Laptop Go 2 from this month to their review of the Surface Book 2 from 2017. The current review only includes other Wintel laptops in benchmarks whereas the one from 2017 included that year’s MacBook.

If memory serves, including Macs in PC hardware comparisons was more or less the norm just a few years ago. I can’t fathom why some reviewers have recently stopped doing so. Is it that reviewers don’t think they could fairly compare x86 and ARM laptops? It seems easy enough to me. Are they afraid that constantly showing MacBooks outperforming Wintel laptops will give the impression that they are in the bag for Apple? I don’t see why. Facts are facts, and a lot of people need or want to buy a Windows laptop regardless.

I can’t help but wonder if, in the minds of many reviewers, MacBooks were PCs so long as they used Intel, and therefore they stopped being PCs once Apple switched to using their own silicon.

When Intel ran its “Go PC” campaign with Justin Long, I criticized the company for commoditizing itself.

Make fun of Apple or not, the goal of this campaign should have been “a laptop without Intel is like a burger without Heinz“. Instead, Intel commoditized itself by creating an ad campaign that highlights all of the benefits of PC laptops regardless of what’s inside of them.

The recent reviews that exclude comparisons between Wintel laptops and Apple Silicon based MacBooks proves that point. Intel could’ve said that a laptop without a processor made by them isn’t a PC. Would it have been fair? Not really, but it would have worked because that sentiment was and seemingly still is in the air.

Update: Since posting I wanted to validate my sense that excluding MacBooks from comparisons from PC laptops was a recent trend so I looked at two sites: The Verge and Ars Technica. The Verge doesn’t really do comparisons, but I found a couple of post-m1 and a couple of pre-M1 reviews by multiple reviewers on Ars Technica, all of which don’t include MacBooks in comparisons. Not only that, I also found what seems to be Wirecutter’s 2018 Best Laptops guide (on Medium of all places), which also leans on the term “ultrabook” and also splits out Macs into a separate category. So there goes my theory that this is a recent trend.

That said, I do think it somewhat aligns with my speculation that whether or not MacBooks are included depends largely on whether the reviewer sees them as relevant to PC laptops. How reasonable that is varies in my mind. While I don’t think MacBooks should be excluded from comparison in reviews of consumer and professional laptops, even I wouldn’t expect to see them in reviews of PC gaming laptops.

Finally, I (and I suspect Gruber) have been on alert about this subject because even laptop reviews that do compare PC laptops with Apple Silicon based MacBooks seem to understate just how much better these MacBooks are in terms of power, noise, and battery life. It’s no longer a choice between a compromised laptop that runs Windows and another compromised laptop that runs macOS. It’s a choice between a hot and noisy and/or slow PC laptop running Windows and a cool, silent, and fast MacBook. Most buyers don’t know that choice now exists, and it’s the reviewer’s job to educate them. Excluding MacBooks from consideration does those buyers a considerable disservice.

I thought it might be a good idea to keep a running lexicon for Stage Manager now that Apple has seemingly named one of its components. As of macOS 13 beta 3, what I’ve been referring to as a “wing”, Apple now calls a “strip”.

• stage – a main area of a screen
• strip – a small left-aligned area where sets and windows live when they are not on a stage
• set – a user-defined collection of windows to be displayed on a stage simultaneously
• stack – a collection of windows and/or sets, organized by application in a strip, to be displayed on a stage individually
• stage manager – the mechanism that manages which window or set of windows is on a stage verses those that are in a strip

Absent of a formal name from Apple, I have been referring to Stage Manager’s dingus on the left as a “wing“. If macOS 13 beta 3 is to be trusted, this dingus is called a “strip“. I still like “wing” better, but a name is still way better than no name.

When I spitballed a lexicon for Stage Manager, I hadn’t yet actually played with the feature. One would think not having actually used a feature would prevent someone from giving feedback. That said, here’s what I suggested regarding Stage Manager specific command+tab and command+` behavior:

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 stage.

Having now tried Stage Manager using Guilherme Rambo’s Virtual Buddy, I’ve discovered that while command+tab disappointingly still cycles between apps, command+` actually does what I suggested… sort of. It’s complicated. As with everything else with Stage Manager, this complication greatly benefits from establishing some vocabulary. Here’s my heretofore Stage Manager lexicon:

• set — a collection of windows
• stage — a main area of a screen
• strip — where other sets live when they are not on a stage
• stage manager — the mechanism that manages which of the sets are on stage verses those that are in a strip.

As of writing that lexicon, I thought that only sets lived in strips. That’s not the case. In addition to sets, a strip can contain another kind of collection which I’ll call a “stack”¹.

• stack — a collection of windows and/or sets that belong to a single application in a strip

This seems simple enough. The complication and my prior confusion stems from the fact that sets and stacks are visually the same in macOS Ventura. The difference is purely functional. When Stage Manager is first enabled, each window is organized by application in a strip. Windows are then stacked whenever an application has multiple windows. Sets containing multiple windows from the same application are still stacked, while those containing windows from different applications aren’t. Multi-application sets necessarily get their own entries in a strip because they can’t logically be stacked within a single application.

All-in-all there are six possible scenarios of how windows can be organized in a strip:

1. A single application window
2. A stack of multiple windows belonging to the same application
3. A set containing windows from the same application, which could be stacked
4. A stack of multiple sets, all of which having windows from the same application
5. A stack of windows and sets, all from the same application
6. A set containing windows from multiple applications, which can’t be stacked

The nuances of these six scenarios become obvious when invoking command+`. Outside of Stage Manager, command+` cycles through all windows of the current application. When Stage Manager is invoked, command+` cycles through all windows in the current set and/or stack. This works surprisingly well in most scenarios. When working in a stack of windows, pressing command+` replaces the current window on stage with one from its stack². When working in a single unstacked set, command+` simply cycles through the windows currently on stage (as I suggested.) Where Stage Manager’s command+` behavior breaks down is scenarios 4 and 5³. When a stack contains sets, command+` will cycle through the windows in a set as well as all other windows in a stack. In these scenarios, it’s impossible to know whether the keystroke will merely raise the next highest window in the set that is currently on stage or bring forward one along with its entire set from the stack.

While Apple might be able tweak command+` to be more intuitive in scenarios 4 and 5, I don’t see how. Instead, I wonder if sets and stacks should conceptually be separated. Currently in Stage Manager, a window can live in a set and a stack. Conceptually separating sets and stacks would greatly simplify how windows are organized in a strip. Instead of six scenarios, there would be just three:

1. A single application window
2. A stack of multiple windows belonging to the same application
3. A set containing more than one window

I don’t even think making sets and stacks mutually exclusive would be functionally all that different from what Stage Manager does today. By default, windows would still be stacked automatically by Stage Manager and sets would still be specified by the user⁴. Command+` would still cycle stacked windows off and on the stage the same way it currently does. It would also continue to simply cycle through windows in the current multi-window set on stage. The only functional difference would be all sets, even those involving one application, couldn’t be stacked and therefore would always have their own entry in a strip.

Here’s an updated list of nouns in a world where sets and stacks are mutually exclusive:

• stage — a main area of a screen
• strip — where sets and windows live when they are not on a stage
• set — a user-defined collection of windows to be displayed on a stage simultaneously
• stack — a collection of windows, organized by application in a strip, to be displayed on a stage individually
• stage manager — the mechanism that manages which window or set of windows are on stage verses those that are in a strip

Sets make sense. Stacks make sense. Conceptually combining the two is confusing, while separating them simplifies Stage Manager without losing any real functionality.

Updates:

• Having slept on this post, I came to the conclusion that “single-window set(s)” is too tortured, and doesn’t accurately represent Stage Manager conceptually. I have reworded the post to simply use the nouns “window(s)” and “set(s)” in lieu of the tortured “single-window set(s)”.
• Additionally, I added a sixth scenario to account for stack of only sets.
• Finally, I aligned how the current and proposed scenarios are phrased.

Update 2: What I’ve been referring to as a “wing”, Apple now calls a strip as of macOS 13 beta 3.

Update 3: I went ahead and replaced “wing” with “strip” in this post since it published the same day that “strip” was first revealed in macOS 13 beta 3.

I decided to use “wing” instead of “deck” as my name for the Stage Manager’s dingus on the left.

Here’s what I wrote in the update to that post:

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.

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 stage^1,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.