From David Pierce, at The Verge:

Football fans, start saving those pennies. YouTube just announced pricing for its new Sunday Ticket package, and access to this season’s games will cost anywhere from $249 to $489.

When Apple didn’t get NFL Sunday Ticket, my guess was that it was because they wanted to do something markedly different with either the pricing and/or the offering itself, and that the NFL just wanted to keep doing the same thing. We’ll probably never know for sure, but these YouTube prices and packages sure look a lot like what DirectTV was previously offering.

Personal computers, including smartphones, are really general purpose computers in that they and their software is built for, well, everyone. Their operating systems and most of their apps are designed to maximally satisfy the most users. The challenge is that everyone has different needs so how can one piece of software accommodate them all? The answer is usually to add more features. Large apps and operating systems are chock full of so many features that how to organize them is subject to criticism and debate.

The most common and sensible way of managing loads of features is to implement some form of progressive disclosure. Rather than attempt to show every feature to everyone all at once, designers put some features behind some sort of control, like a dropdown menu or button. Implementing progressive disclosure requires software makers to prioritize which features should be most easily accessed and a natural way to rank them is usage. Sensible user experiences only present the features its makers believe will benefit the most users. The most prominent features in Apple Music, for example, is arguably the back, play/pause, and next buttons. This makes sense because everyone listening to music will necessarily have to play and pause, and are very likely to want to skip ahead or go back to replay a song at some point.

Being a large app with everyone in mind, Apple Music also has a ton of features and employs progressive disclosure to tuck away those less commonly used behind various UX. One less commonly used feature in Apple Music that I frequently use is star ratings, which Apple Music hides behind hover states and menus. While certainly reasonable design, it’s an example where an app’s progressive disclosure doesn’t align with my personal needs.

My situation is neither unique nor is it limited to only advanced users. I’d wager millions of users needlessly and repeatedly perform some additional click or command to get past some bit of progressive disclosure in order to reach some feature they frequently need. Heck, given some apps have hundreds of millions of users it’s easy to imagine a single “less common” feature that is frequently used by millions of users. You might think this is bad design, but in many cases it’s unavoidable. Obscuring a feature used by millions sounds bad until you consider the other features that are frequently used by tens of millions.

This is where personal automation comes in. Personal automation gives individuals the ability to choose which of their features should be most easily accessed. I used Shortcuts and AppleScript to elevate star ratings using dedicated keys on my Stream Deck. Now I can rate songs regardless of what app I am currently using, and in one step instead of five. Using personal automation, I have also changed how Time Machine works, streamlined pasting links from Safari, and made joining Zoom meetings practically effortless.

Personal automation doesn’t need to involve expensive third party hardware, or require scripting. It can be something as as simple as customizing keyboard shortcuts¹ or defining text replacement macros. Apple’s Shortcuts app is completely drag-and-drop, and makes building personal automation easy enough for even basic users. On top of the many automation apps and features included with Apple’s platforms, there are also a slew of great third party apps that unlock even more possibilities.

Personal computers have become easier and more accessible, to the point where they and their apps are necessarily built for everyone. That’s truly great, but being easy and more accessible doesn’t make them personal. It makes them general purpose. Personal automation gives individuals the power to make their general purpose computer that was built for everyone actually personal.

Matt Birchler wrote what I can’t help but feel was a rebuttal to my piece arguing that you can’t have a maximally productive touch UI on a portable screen. Here’s what I wrote:

It’s foolishly optimistic to think that Microsoft or even Apple can make pointer interfaces as touch friendly as iPadOS without also destroying the very thing that makes them more productive than iPadOS — information density. Smaller controls means these platforms can disclose more information and interactivity to their users at once. That’s why a bunch of windows on even an 11″ MacBook Air feels natural while only four windows on a “large” 13″ iPad feels ungainly.

And here’s what Birchler wrote, after comparing UI density on a 14″ MacBook Pro and an iPad Mini:

There’s a narrative out there that touch is just so incompatible with macOS and that in order to make it work, the macOS UI would have to get blown up to comical proportions, but I don’t think that’s the case. Changes will be made, but I think macOS is more touch-friendly today than many people give it credit for.

While I certainly wouldn’t hold up an iPad Mini as an ideal of touch friendliness, I actually agree that there are many aspects of macOS today that lots of people wouldn’t have any issues interacting with via touch. I also agree with Matt that changes can be made to macOS to better facilitate touch input without blowing it up to comical proportions. That agreement may come as surprise to anyone who read these sentences from my last piece.

Don’t try to make macOS touch friendly. Add touch and pencil support, but leave macOS’s interface unchanged.

Agreeing with Matt today after writing these sentences two weeks ago doesn’t mean my opinion has suddenly changed in the intervening time, rather it means that these two sentences require more elaboration than an off-the-cuff remark in a bullet point.

When it comes to adding touch to macOS, I think there are three camps:

1. Apple shouldn’t add touch to macOS.
2. Apple should add basic touch support to macOS for things like gestures and tapping on buttons to meet the expectation of a population that increasingly assumes touch is supported.
3. Apple should reinvent macOS to create a touch first experience on par with iPadOS that is also somehow as productive as macOS is today.

I have been firmly in camp 2 since 2018, and I really do think there are areas of macOS that either already are or can be made as touch friendly as an iPad Mini without meaningfully sacrificing information density. That said, implicit in “don’t try to make macOS touch friendly” is “don’t try to make macOS touch friendly as iPadOS“. Adding a smattering of touch friendly controls won’t make macOS nearly as touch friendly as iPadOS.

The reason my last piece started with a series of quotes from an increasingly frustrated Federico Viticci is that I get the sense, perhaps incorrectly, that a driving force behind camp 3 is disgruntled iPad Pro users who are still dissatisfied by being productively limited on their preferred platform, and now think that some hypothetical new version of macOS that is designed for touch could be the platform of their dreams. This is because Macs today already solve many of their needs. They are more powerful, have better support for third party peripherals and software, and have the same great battery life and lower temperatures thanks to the same Apple Silicon found on their iPads. The only thing keeping the Mac from being the platform of their dreams is lack of touch support, but not just any touch support. What I suspect iPad Pro users ultimately want is the same touch first experience found on their beloved iPads today. The crux of my argument is that there is a tension between touch friendliness and information density that makes what camp 3 wants impossible on any platform.

The lesson to take from this half decade of disappointing iPadOS and iPad Pro updates is not that the iPad platform is fatally flawed and that Apple needs to jump ship to macOS for its pro tablet OS. It’s that Apple’s been trying to solve what increasingly seems like an impossible set of constraints — touchability, productivity, and portability. It’s foolish to think Apple or anyone can move those same constraints and demands to a different platform and assume a better outcome. I am all for adding touch support to Macs, but that won’t satisfy the dreams of iPad Pro users who want the same touch first experience found on their iPads today. Furthermore, overhauling macOS¹ to create a touch first experience would only introduce the same problems found on iPadOS today, and if that’s the case, then what’s the point?

The venerable Federico Viticci has done it again! He has eloquently captured the iPad’s simplistic beauty…

The iPadOS UI, particularly in tablet mode, feels nicer than any other tablet I’ve tried to date.

…while simultaneously lamenting its low productivity ceiling.

The problem is that an iPad, at least for people like me, isn’t supposed to be a companion to work that happens somewhere else. It is the work.

Along the way, Viticci doesn’t pull any punches with his fundamental dislike of Apple’s Stage Manager.

I fundamentally dislike Stage Manager

There’s more.

I feel this every time Stage Manager doesn’t let me place windows where I want on an external display; every time I can’t place more than four windows in a workspace…

And finally…

The more I explore other platforms, the more I believe that iPadOS looks and feels nicer, but it’s also getting in the way of me being able to get my work done. Maybe this has been true for a while and Stage Manager was the proverbial straw that broke the camel’s back.

In Federico’s mind, Stage Manager is the poster child for iPadOS’s low productivity ceiling when compared to other platforms. Not only do I agree, his words stoked a very strong reckon I’ve been feeling with regards to the tension between information density and touch friendliness.

Before the Apple community was waxing poetic about art in software, we were all in a tizzy about Mark Gurman’s report that Apple was exploring Macs with touchscreens. Some might see a touchscreen MacBook as the device Federico and others have been wanting for over a decade — a great tablet that doesn’t sacrifice productivity. While I’ve been on the “Macs should have touchscreens” train since 2018, I don’t think they can solve the problems found on the iPad.

What makes a great tablet first and foremost is touch friendliness. The iPad is extremely touch friendly. The Apple Pencil exists and is great, but you don’t need one to use iPadOS. An app that had buttons or other controls small enough to require a stylus would feel broken to any iPad user. Compare this to the other major tablet platform, Windows. Windows does not make for a great tablet OS in large part because it isn’t entirely touch friendly. PC makers include a stylus, not just out of the goodness of their hearts, but because they have to. Windows apps new and old are littered with controls that require input roughly the size of a mouse pointer because Windows itself was built for a mouse.

The Mac was also built for a mouse, and while I would argue macOS is more usable than Windows, there is no getting around the fact that controls optimized for pointers are inherently unfriendly to touch input. It’s foolishly optimistic to think that Microsoft or even Apple can make pointer interfaces as touch friendly as iPadOS without also destroying the very thing that makes them more productive than iPadOS — information density. Smaller controls means these platforms can disclose more information and interactivity to their users at once. That’s why a bunch of windows on even an 11″ MacBook Air feels natural while only four windows on a “large” 13″ iPad feels ungainly.

Conversely, it’s impossible to make iPadOS more information dense without sacrificing the very thing that makes it the best tablet OS — touch friendliness. iPad users want more information on screen because that will help them be more productive, but the only way to present more information in iPadOS without sacrificing touch friendliness is a larger display. Not only is a larger display not portable, iPadOS’s support for larger displays still sucks. There’s nothing Apple can do about large displays not being portable, but better support for larger displays? That’s a problem Apple can solve.

Given macOS can’t be made touch friendly without sacrificing information density and iPadOS can’t add information density without sacrificing touch friendliness, here’s what I think Apple should do:

1. Don’t try to make macOS touch friendly. Add touch and pencil support, but leave macOS’s interface unchanged.
2. Shitcan Stage Manager on iPad screens. It was a stupid idea to begin with.
3. Make iPadOS windowing awesome whenever an iPad Pro is connected to a large screen.
4. Release a “Studio Display Touch” that works with both iPads Pro and Macs, and can be ergonomically adjusted for touch and Apple Pencil input.
5. Bump the specs on iPads Pro to their Mac equivalent. Don’t artificially restrict how many apps can be open on a large display.
6. Leave non-Pro iPads as just tablets.

If someone walks into an Apple Store wondering what to buy, they would have three great options given the above. If they want a portable device for maximum productivity, they could buy a MacBook. If they want a portable, touch friendly device. They could buy a non-Pro iPad. If they want a portable, touch friendly device that can also do more given a large screen, they could buy an iPad Pro.

What you don’t want is that same person being presented with a MacBook and an iPad that each have distinct terrible experiences that separately fail to solve the impossible task of being simultaneously touch friendly and maximally productive while still being portable.

From Wesley Hilliard at AppleInsider:

An engineer called “Technology Hunter” on Chinese social media site Bilibili attempted to redesign the 24-inch iMac with a uniform display bezel. He moved the chin to the rear of the display, enabling a Studio Display-like bezel.

It’s an impressive mod, without a doubt, but is the resulting design better than the iMac Apple is shipping today? To my eyes, moving the components to the rear of the display is less clearly elegant. Furthermore, it’s obvious the added bump reduces the iMacs range of tilt. What’s less obvious is how this design impacts the iMac’s already poor ergonomics. Regardless of whether you like or hate it, it’s inarguable that the chin raises the display¹. By merely removing the chin, “Technology Hunter” also lowered the display. I don’t think a chinless iMac is impossible, but I do think designing a chinless iMac involves a lot more than simply replacing a chin with a bump.

The car I learned to drive on had a manual transmission. That was over two decades ago, but learning on stick was still relatively uncommon among my peers. Driving a manual was (and still is) harder than an automatic. You have to time the clutch just right to get going lest the car stalls or lurches forward too quickly. In some settings, this hard work is rewarded. I find driving stick way more satisfying in hilly rural settings. That said, most driving is not done on hilly rural settings, but in stop and go traffic, where manual transmissions become burdensome at best and annoying at worst. Being harder and more annoying is why almost every car sold in the U.S. today has an automatic transmission.

Windowed interfaces, like those found in macOS and Microsoft Windows have historically been manual. The user opens, arranges, closes, minimizes and hides windows in whatever manner that suits their needs. When Mac OS and Windows came of age in the 80s and 90s, computers were only powerful enough to do a few things at once. These limited resources meant a given task typically involved launching a few apps, manually managing their small number of windows, then closing everything before starting the next task. Like driving stick on hilly rural roads, I find managing a small number of windows more satisfying than burdensome. Users on today’s computers can easily amass dozens of windows from a variety of apps. Furthermore, these apps and windows persist, even between reboots. There is no intrinsic impetus that forces users to quit latent apps or close latent windows. Manual windowed interfaces became cognitively burdensome when faced with unlimited persistent windows found in modern desktop computers. While some still find them delightful, more and more people find desktop computers harder and more annoying.

So what do you do?

Get Rid of Windows

The first solution to desktop computing’s window problem was simple: get rid of the windows. The first iPad, like the iPhone before it, only displayed a single app at any given time. People loved this simplistic model, but limiting interaction to just a single app came with an obvious trade-off — multitasking. While navigating between iPad apps was incredibly easy, working with more than one app at a time became incredibly difficult, if not impossible. The original iPad replaced users’ cognitive burden of having too many windows open at once with a functional one that limited what they could do.

Slides, Splits, and Snaps

In 2015 with iOS 9, Apple addressed the iPad’s multitasking burden in two ways: Slide Over and Split View. Slide Over let users designate an app that they could slide over from the left or right side to interact with. Once users returned to the primary app, the slide over app would slide back off screen from whence it came. Split View, by comparison, let users have two apps open side by side on screen at the same time.

In my mind, Split View is along the same lines of what I’ll call “gridded UIs”, where apps are laid out in a grid. Microsoft has recently been pushing it’s gridded solution in Windows 11, called “Snap”. Here’s how Microsoft describes it:

Organize what’s on your screen in a snap so you can bring out your best ideas. Just drag a window to the edge of the screen to activate Snap assist and “snap” them into a clean, organized grid.

The difference between iPad’s Split View is that Snap makes it possible to arrange apps vertically and horizontally so, for example, you can have a 4×4 grid.

Fundamentally, these sort of gridded UIs all try to mitigate the complexity and burden of multitasking by preventing persistent overlapping windows. Simply put, only so many apps can fit in a single display at the same time. Personally, I’ve found gridded UIs to be lacking ever since I first saw Windows 1.0. When using grids, apps’ sizes. and more importantly their aspect ratios, are dictated by other windows that are on screen. Say you want to work across a spreadsheet, word processor, and a browser. Not only do all of these apps benefit from a large amount of screen real estate, both the word processor and browser need a minimum amount of size just to be entirely visible. In a gridded UI, some or all apps would have to compromise on space and you would have to scroll constantly within each app to see the entirety of what’s being worked on. I would also argue gridded UI’s don’t provide more focus as they visually give each app the same depth.

Full-screens, split views and grids all treat overlapping windows as part of, if not the root cause behind, burdensome window management. To me that’s throwing the baby out with the bath water. While there is no question in my mind that windowed interfaces have become burdensome to most users, I don’t think overlapping windows are the problem. It’s that there are too many of them and they all need to be manually managed.

This is where Apple’s Stage Manager comes in.

Stage Manager — Automatic Window Management

I have been using Stage Manager in macOS Ventura on my home machine for about two months. Unlike the full-screens, split views and grids before it, Stage Manager supports as many windows as desired (at least on macOS Ventura) and even embraces overlapping them. Rather than physically constrain the dimensions and number of windows that can be open at once, Stage Manager instead reduces the cognitive burden of multiple windows by automatically managing which ones are currently on screen. Windows from apps not currently being worked are automatically minimized or hidden. The result is a much cleaner and more focused workspace.

Stage Manager is enabled from Control Center. When Stage Manager is enabled, three things happen:

1. The current app’s windows are left on the main portion of the screen, called a “stage”.
2. Windows from the four most recent apps are organized by each app and minimized into a “strip”.
3. All other windows are hidden.

Clicking on an entry in a strip¹ replaces the current window or set on stage with that entry’s window or set. Apps not currently in Stage Manager can still be easily added by either the dock or the command+tab switcher. Whenever a new app is brought into Stage Manager, the least most recent one in a strip will be pushed out.

You might read that and think Stage Manager only shows one app on the stage at any given time and wonder how it could possibly be an improvement to multitasking. That is indeed how Stage Manager works without any user intervention and left to that, it would definitely be a disaster for multitasking. Thankfully, there’s more to the story.

Sets are a collection of multiple windows to be displayed on a stage simultaneously. Clicking on a set in a strip brings all windows belonging to that set to a stage. Conversely, a set of windows currently on a stage will all minimize into a single entry in a strip whenever it’s replaced. Stage Manager automatically organizes multiple windows belonging to the same apps into sets by default, but users can also create sets with windows from multiple apps.

In my experience, user created sets are where Stage Manager shines. The set I am currently using while writing this review has windows from BBEdit and Safari. I also have sets for Discord and Slack, as well as Twitter and Tweetbot. I look forward to having Visual Studio Code and Terminal sets once I am allowed to install Ventura on my work machine. Sets let me focus on the work at hand by reducing the clutter while still keeping other windows and apps visually close at hand.

Sets fundamentally change the UI Hierarchy in macOS. Historically, windows in macOS typically belong to apps. This hierarchy is evident when using keyboard navigation where command+tab cycles through apps and command+` cycles through windows of the current app. In Stage Manager, windows belong to sets. As such, invoking command+` cycles through windows of the set currently on stage². I am sure other old Mac users will hate this, but I love it and think Apple needs to take it further. I think of this set containing windows from BBEdit and Safari as a pseudo app of sorts. One that contains the windows for the work I am doing right now. In that sense, having command+` to conveniently switch between these two windows is way more useful to me than cycling to some window that happens to belong to the same app, but is irrelevant to my task at hand. My biggest complaint with Stage Manager is that they didn’t take it further and update command+tab to include my user defined sets.

Changing command+`, but not command+tab takes me to my overarching criticism of Stage Manager. While functionally solid compared to it’s iPad counterpart, Stage Manager in macOS Ventura feels disconnected. In addition to the lack of keyboard shortcuts, there is also no automation support for Stage Manager. The lack of AppleScript support, while disappointing, is unsurprising, but there aren’t even any Stage Manager actions available in Shortcuts. Furthermore, while I love Stage Manager’s sets, adding windows to existing sets is often needlessly cumbersome. While you can easily add windows already in a strip (either by dragging or shift+clicking them), there is no direct way to add an app outside of Stage Manager to an existing set. Instead you have to let Stage Manager open the app separately, then return to the set in question before finally adding said app’s window from the strip. That you can’t add an app to the current set directly from the dock is maddening.

Given the lack of functionality around managing and navigating sets, I can’t help but feel Stage Manager was born out of a tension between being a focus mode while also introducing the concept of window sets. This is illustrated by the “Show windows from an application” drop down in Stage Manager’s settings, where two options are presented:

• All at Once: Show all available windows for an app when you switch to it.
• One at a Time: Show only the most recently used window for an app when you switch to it.

In earlier betas, the default was “One at a Time”. In other words, Stage Manager prioritized maximal focus by showing only one window at a time. The default changed by the time of release to “All at Once”. Both options are reasonable, and while I don’t think sets and focus are entirely at odds, changing the default is a clear example of this tension and makes me wonder whether those working on Stage Manager lacked a clear north star.

Despite these criticisms and concerns, I think Stage Manager in macOS Ventura still effectively alleviates the burden of too many windows. My hope is that Apple continues to iterate on Stage Manager in ways small and large. In addition to adding automation support and improving keyboard shortcuts, I want to see Apple further examine how sets holistically change the UI hierarchy in macOS. Even as it is today, I expect to have Stage Manager enabled more often than not.

My larger take from using Stage Manager is that window-based UIs really haven’t kept up with the capabilities of modern computers. It’s easy to look at a UI with too many windows and conclude that it’s the windows themselves that are bad, but here’s the rub. People wouldn’t be opening new windows if they weren’t useful. What if the problem of “too many windows” isn’t that windows are bad, rather that they actually work so well that it’s easy to keep adding them until there’s too many of them to manually manage? And if that’s the case, does it really make sense to get rid of them?

People still drive cars with transmissions, it’s just most of them don’t have to think about it because they bought an automatic.

Update: Changed “hundreds of windows” to “dozens of windows”. While people do have too many windows, “hundreds” was an overstatement.

This paragraph by Scharon Harding at Ars Technica made me do a double take.

Regardless of what I put it through, the Spectre stayed surprisingly cool for its size. After an hour-long stress test, for example, the only part of the chassis that was too hot to touch comfortably was its underside, although the keyboard was borderline.

At first I was convinced I must have misread it, because who would write what is effectively the review version of “This is Fine” with a straight face? After rereading it several times at this point, I am certain I read it correctly and I am mostly sure it was written with a straight face. The only remaining question is “how?” What mindset is required to frame a laptop getting too hot to sit atop one’s lap as “surprisingly cool”? John Gruber called it a form of Stockholm’s Syndrome.

The phrase “Stockholm Syndrome” gets overused, but I think PC hardware reviewers are in a deep state of denial as to how high Apple silicon has raised the bar for performance-per-watt, in day-to-day practical terms.

I agree, but don’t think PC reviewers are the only ones with Stockholm Syndrome. I think it’s most laptop users. When changing jobs last fall, I pushed for and got an M1-based Macbook Pro from my new employer and strongly advised others in my position to do the same. Since joining this company, I’ve also been telling new colleagues with older Macs to push for an upgrade. In both cases, I evangelized how Apple Silicon based Macs run silent and cool all while outperforming their Intel-based counterparts. In most cases, my evangelism was met with a sort of shrug. It’s not because these folks didn’t care. They acknowledged that hot laptops and fan noise are bad, but they’ve so internalized those trade offs as inherent to using a laptop that they’ve dismissed the notion that one could run cool and silent for their needs.

I’ve long felt that Apple sometimes gets too brand focused in its advertising, and have more recently been thinking they need to be more aggressive in touting their performance-per-watt advantage. Give me an ad with a mic’ed up PC loudly running several Chrome tabs before cutting to a MacBook running silent. Give me another comparing temperature readings between the the two devices.

Apple’s advantage right now is so unbelievable that it has to be seen to be believed, and so Apple should be doing everything in its power to make sure everyone sees that a hot and loud laptop is no longer fine.

A reader recently sent me a screenshot of macOS Ventura’s onboarding prompt to enable Stage Manager (as of developer beta 5). Here’s what it says:

Stage Manager

Stage Manager arranges your recent windows into a single strip for reduced clutter and quick access. Focus on one window at a time and create sets by mixing different apps to suit your workflow.

Not surprisingly, I have many thoughts on this.

First off, I am very happy to see Apple continue to embrace a vocabulary for Stage Manager. This text furthers the use of “strip”, and also formally uses “sets”. I also appreciate how the text establishes that while “Stage Manager arranges your recent windows”, it is you, the user, who “creates sets”.

That said, I find describing sets as “mixing different apps” vexing. As I have written a few times before, a set is really any user-defined collection of windows. You can create a set of windows from one app just as you can with windows from multiple apps. The seemingly deliberate use of “apps” here and in Stage Manager’s settings¹ is worrisome because conflating apps with windows feels iPad-centric to me. I am sure some might read that as shade from an old Mac curmudgeon, but it’s hard to argue otherwise. While related, apps and windows in macOS are logically separate. It’s common for an app to have multiple windows and closing a window doesn’t typically quit the app. Compare this to iPadOS where apps and windows have historically been more or less synonymous. Most apps involve just a single window, and force quitting an app in iPadOS is visually done by dismissing its window-like card.

With Stage Manager, you would think iPadOS would adopt more of macOS’s windowing paradigm, especially given the existing state of multitasking in iPadOS is so bad that a vast majority of iPad users don’t use it, let alone dare use it with multiple windows. Instead, macOS is nonsensically conflating apps and windows like iPadOS. Why? I can’t help but wonder if windows in iPadOS still only has tepid support within Apple, and that said tepidness has now bled into macOS because of a desire to make Stage Manager consistent across both platforms. The seems farfetched, but just look at how Stage Manager is described in Apple’s preview of iPadOS 16 (emphasis mine).

Introducing Stage Manager

A new way to multitask and get things done with ease. Resize windows to look the way you want. And for the first time on iPad, see multiple overlapping windows in a single view.

Switch between apps

Switch between apps seamlessly with just a tap, or a click of the mouse or trackpad.

Create your ideal workspace

Make different groups of apps for specific tasks or projects. And arrange, resize, and overlap them in your ideal layout.

External display support

Use iPad Pro or iPad Air with your external display, with resolutions up to 6K, using Stage Manager. View multiple apps on both your iPad and external display. Drag and drop files and apps between screens.

While the introduction is all about windows, every sub-section thereafter talks about apps. It’s possible that Apple prefers “apps” over “windows” for marketing purposes. “Apps” is a term Apple coined and largely owns whereas “windows” happens to be a fiendishly brilliant name used by a dominant competitor. I think that’s a fair hypothetical marketing argument, but marketing is transient. Software sticks around, and a poor label in software can last decades.

For arguments sake, let’s swap “mixing different apps” with the more accurate “combining multiple windows” .

Stage Manager arranges your recent windows into a single strip for reduced clutter and quick access. Focus on one window at a time and create sets by combining multiple windows to suit your workflow.

Not only is this description more accurate, it’s also much clearer. Comparing “one window” to “multiple apps” is apples and oranges (or I guess “apple and oranges” in this case). While it does initially organize windows by app, Stage Manager ultimately manages windows. Apple should embrace this on the Mac, which can easily have an overwhelming number of windows, and they should also embrace it on the iPad, which has long needed resizable overlapping windows. Stage Manager is an automatic window manager, one that I think could be really nice on both platforms, but obscuring the role windows in a window manager is folly and I worry could undermine that potential.

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?