Thread by @tolmasky

I think the history of tabs serves as a fascinating case study of how Apple's neglect for its own UI frameworks assisted the rise and acceptance of cross-platform frameworks like @electronjs and the corresponding decline in the importance of "nativeness" and "the HIG". 1/🧵

Tabs made their first appearance in NetCaptor in 1998, and by 2003 were considered such a killer feature that they made their way into the beta of Safari, to much fanfare. Today, tabs are of course considered a critical feature in every browser. 2/🧵

But more importantly, they've since become expected in just about every document-based app. The problem was, tabs were difficult to implement on the Mac since there was no built-in component and it was hard to make them fit into AppKit's NSDocument/WindowController model. 3/🧵

Although Apple had shipped tabs in Safari, developers were left to their own devices to figure out tabs for the individual apps. Critically, this was true both in terms of implementation and *behavior*. With no AppKit component, there was no strong Apple direction for tabs. 4/🧵

Normally, in these cases the dev community tried to copy Apple components. This was a favored approach for mimicking pro apps e.g. But Safari tabs don't necessarily give you all the answers for editing-heavy apps, and let's not forget, Safari tabs were weird and upside down! 5/🧵

So what ended up happening is that a major facet of 2000's UI ended up getting developed, organically, and inconsistently, by each developer's different take on it. Some tried to follow Safari's model, others made more traditional tabs (like TextMate). 6/🧵

This may seem mundane, but it represents a first major instance of Apple ceding control of the Mac experience to the emergent behavior of the ecosystem. You'd never have expected Apple to let that happen with the position of the window close button or Dock minimization! 7/🧵

Just ask yourself, do you consider "tabs" to be a well defined feature in macOS that you'd get angry at an app for deviating from? Not unless it deviates as much as Monterey Safari, right ;) 8/🧵

Apple did eventually end up adding an API for tabs to AppKit, but not until *2017*, 12 years after they shipped their first tabs in Safari! By that point, it was more of a pain to convert legacy code than anything, and it wasn't helped by a woeful lack of documentation. 9/🧵

For a long time, the best resource on how to use AppKit’s tabs was a single WWDC video. And of course, being new, it lacked many of the features existing apps had already implemented. It was too late, now it was a "chore,” not a "feature", and with little perceived benefit. 10/🧵

What's important here is that there are two critical components in achieving a consistent OS: the vendor must offer both a strong vision of how things should work, and *also* provide an easy avenue for making things work that way. Apple has been failing at both on the Mac. 11/🧵

And this eventually leads to a much bigger problem: through this inaction, users are slowly acclimated to a chaotic app ecosystem. If key modern features are defined "organically," that expectation begins to bleed over to the old features as well. 12/🧵

If tabs work differently in every app, then why should they expect drag and drop to be any different? Not to mention geekier features like key commands? The entire UX expectation is eroded as consistency increasingly becomes the exception, not the rule. 13/🧵

This of course isn't helped as Apple's own Catalyst apps often fail to adhere to any rules as well, giving users even fewer examples of "the way things should be." (or perhaps, "the way things used to be"). 14/🧵

But again, tabs are just one case study, versions of this have been happening throughout all of AppKit and the UX on macOS in general, exacerbated by complete top to bottom (buggy) OS redesigns that solidify in users the idea that UX consistency is secondary to aesthetics. 15/🧵

In the last decade, macOS has slowly been allowed to degrade into an environment where there are increasingly fewer downsides to counteract the benefits of going non-native, and that’s not on developers. It’s been a long time coming, and it isn't going to be easy to fix. 16/🧵