Coyote Cartography

Those of you not plugged into the Mastodon community may not be aware of the predominant reaction to Instagram Threads. This started when it was merely rumored, reaching a crescendo with reports that Meta had been talking to a few of the larger Mastodon instances under NDA, presumably to encourage them not to “defederate” with Threads when it came online.¹ Let me describe that reaction for you, with only mild exaggeration:

Meta is coming! If Threads is allowed to become part of the Fediverse, it will destroy it! It will steal your data! It will inject ads onto your timeline! It will corrupt Mastodon into being everything you hate about Facebook and Twitter combined!

Let’s stipulate that Meta has a long history of doing demonstrably bad things, and that the argument I’m about to make—that Threads is not what people on Mastodon believe it is—should not be mistaken for an argument that Meta is just here to give everyone free cookies. Daring Fireball’s John Gruber has written extensively about how Facebook wanted NSO spyware to monitor iOS users, produced their own spyware VPN and pushed it within their mobile app, and how Facebook’s “unknowable megascale” created “societal harm…as easy for anyone to see as the respiratory problems caused by smoking.” Threads is a product of that data-tracking, spyware-installing, society-harming Facebook, and it is not joyless unreasonable alarmism to keep that in mind when we evaluate how fun and interesting it otherwise may be.

Having said that, Threads is not an attack on Mastodon to subvert it for nefarious purposes.

How can I say that so confidently? Because Threads is not a Mastodon instance. It is its own self-contained, centralized social network with plans to let its users follow Mastodon accounts and vice versa.

The difference is not mere semantics. Mastodon doesn’t care what client software you use—or even what server software you use. Threads does. Threads needs you to use their app. It’s baked into the business model. Facebook and Instagram never killed their robust third-party client ecosystem the way Twitter and Reddit recently did, because they never had one. They understood their business model from the get-go.

When push comes to shove, Threads is Instagram. That’s how, as of this writing, it already has over 100M accounts created. If you have an Instagram account, you have a Threads account. If you get a Threads account, you get an Instagram account. Threads has zero-effort access to over one and a half billion users who, by definition, tolerate Meta’s privacy policies and Instagram’s monetization strategies.

By contrast, Mastodon is maybe two and a half million users on a network explicitly positioned as “social networking that’s not for sale”. The users are much less receptive to monetization strategies. And as Mastodon founder Eugen “Gargron” Rothko notes, the design of the network makes it effectively impossible for Threads to collect personally identifiable information on Mastodon users merely interacting with Threads users.

So, on one hand: a billion users who accept Instagram showing them ads, algorithm-jamming their timelines and hoovering up as much personally identifiable information about them as they can. On the other: two or three million users on an explicitly anti-corporate platform engineered to be highly resistant to leaking private data. I dare you to make a convincing business case for Facebook spending a single cent trying to capture a fraction of the second group, when it’s less than a percent the size of the first group.

Threads is not now, and never will be, about Mastodon. It’s not about embracing it, extending it, or extinguishing it. It’s not about it at all.

So if Threads isn’t trying to overwhelm and destroy Mastodon, why have ActivityPub support at all? Two answers. First, “Look, see? We’re open!” is not only perceived as a great talking point these days, it’s perceived as a regulatory relief valve. Look, see? ActivityPub! We’re open!

Second, remember that the business model for Threads is keeping you on Threads. If 95% of your friends are on Threads but 5% are over on that weird Mastodon thing, now you don’t have to use Mastodon to follow them! Just follow them from Threads! Woo! Will Threads be a good Mastodon client? No, but it just has to hit “good enough.” Will any Mastodon client be a good Threads client? Fuck no. They don’t want you accessing Threads from Ivory or Tusky or Elk, they want you accessing it from the Threads app, guaranteed to show you as many ads and gather as much data as possible.

The argument Mastodon is collectively mustering against Threads is, at the end of the day, “but Facebook is evil!” Again, no argument. But Mark Zuckerberg is evil in the way of a greedy, privacy-flouting tech bro, not in the way of Sauron.² Not only would the “extinguishing” part of “embracing, extending and extinguishing” Mastodon be extremely difficult at a technical level, the plausible ROI on doing so would be minimal at best—and probably even counterproductive.

Yeah, but should people defederate?

The aforementioned John Gruber is bullish on Threads’s chances, and he wrote “Threads is the most fun, most interesting new product of the year” on Mastodon (while taking a swipe with “have fun over here in the library,” as if libraries are terrible sad stern places, a weird dig for a professional writer to make, John). Seriously, while I love the estimable Mr. Gruber’s writing, when I look at Threads what I see is an influencer-infested, brand-driven, algorithmically-jammed-up crapfest. A lot like, well, modern Instagram, without the silver lining of pretty photographs.

My point is that Threads and Mastodon are already really different culturally. Even when-slash-if the ActivityPub bridge exists, I don’t think many Threads fans will rush to follow us Mastodon users over here having fun in the library, nor will many Mastodon users be rushing to follow their friends on Threads through the Mastodon client of their choice. I predict the vast majority of people who want to use both networks will maintain separate accounts to do so.

Instagram has thousands of content moderators, and while they’re already making decisions that will make everyone mad, they’re clearly making decisions. While I doubt Threads will officially follow the Mastodon Server Covenant, in practice I suspect they’ll be more strict in some respects. Instagram has a puritan streak that Threads will carry through—there’s a non-zero chance that Threads may refuse to federate with your instance because, I don’t know, you allow titties and people who say “fuck”. The chances of Threads becoming a conduit for harassment on Mastodon are slim.

Personally, I would federate with Threads in “silence” mode: my instance’s users would be able to follow Threads users and vice versa, but posts from Threads would not show up in any public timelines on my server. I think, though, this should be a choice each instance makes with input from their users, and it is a little dismaying how many instances are perfectly happy making that decision unilaterally.

The truly toxic idea, though, is that Mastodon instances should not only refuse to federate with Threads, but they should refuse to federate with other servers that do federate with Threads. In other words, users should be punished for decisions they have no control over and may not even be aware of, made by the administrators of servers they don’t belong to. I am dead serious when I call this toxic. The default position must, must, be that breaking your users' social graphs is a last resort against clear and present danger. A server explicitly welcomes Nazis, child porn, TERFs, and serial harassers? Block that fucker. But it’s absurd to insist that federating with Meta’s general-interest server presents the same threat level.

Look. At the end of the day, I’m a Mastodon partisan. But I don’t love its collective tendency toward self-important dogmatism. I’ve seen more than one friend get set up only to pull back, worrying there are dozens of unwritten rules about content warnings and alt text and linking and boosting they will constantly be put on blast over. I have never seen so many self-identified queer leftists reflexively drop into well, actually mode.

New users frequently get stuck on the “pick an instance” part of Mastodon’s signup, and we always say oh, it doesn’t matter that much, which is just not true. Some instances seriously up the unwritten rule count; some suck at moderation, and the admins go tinpot dictator when they’re called on it; smaller ones get their plugs pulled with some regularity.³ How much worse will it be when hundreds of small-to-medium servers decide they won’t federate with the largest servers—the ones new users who took our “don’t stress about picking your instance” advice ended up on—because those servers have chosen not to block Threads? That level of fracture won’t preserve the Fediverse, it will mortally wound it.

The truth is, Threads is not about Mastodon. It’s about Meta and only about Meta, and Mastodon isn’t important enough to them to spend the considerable effort that would be necessary to destroy it. It’d be awfully damn ironic if the Fediverse decides it’s become necessary to destroy itself to stop them.

So I’ve been seeing arguments for why, no, you should really stay on Twitter, because of the problems with anything vying to replace it. Most circle around what tech people might dub failure modes in terms of both engineering and policy.

Make no mistake, many of these are solid arguments. Twitter has, as much as we like to pretend otherwise, gotten many things right. They’ve got fast onboarding. They provide a good experience on both mobile and desktop. (Please don’t @ me with your objections to ads and algorithms and whatever; I’m not saying the UX design on Twitter is perfect or free of dark patterns, I’m saying that it’s been developed by UX professionals over a 15-year period and it shows.) They understand the importance of making a service like theirs accessible. They understand the importance of well-designed terms of service that limit their legal liability without taking draconian stances toward users and their content. These are all failure modes that other, newer, smaller services have done little or nothing to address.

But for many people, the real issue isn’t what’s wrong with the other places. It’s that they love this place. Twitter, for all its faults, for all the love/hate relationship you have with it—it’s your favorite bar. This is what most indie creators are feeling, I think. None of the other services have the audience reach; it’s unrealistic to expect us to be on a half-dozen new sites when we could just stay put; and, hey, the likelihood of Twitter really exploding is pretty low. All of those are true, too.

The problem, though, is that just because Twitter’s failure mode isn’t likely to be “closing up shop” doesn’t mean it doesn’t have other failure modes. You might have noticed I didn’t mention harassment and toxic behavior as a failure mode—the things a Trust and Safety Team handles—but it is. As Nilay Patel observed, the product of a social network is content moderation.

To be clear, this is something all the Not-Twitters are going to have to come to grips with in ways they haven’t yet. Cohost, Hive, and OoobyBloobly (which I just made up, or did I, you’re not sure, are you) look good by comparison because they are a fraction of a fraction of Twitter’s scale. Your favorite Mastodon instance this week is even smaller. With Twitter’s two hundred million users, trying to regulate bad behavior is a 24/7 rearguard action.

Well, guess what? Twitter’s Trust and Safety Team is now gone. By deliberate design. It’s not coming back, at least not in any recognizable form, not any time soon.

You think I’m going to mention Musk restoring Trump’s Twitter account. I am. But the canary in the coal mine isn’t the who as much as it’s the how. Musk claimed in October that he’d set up a new “council” for moderation, and that “no major content decisions or account reinstatements will happen before the council convenes.” That was a blatant lie. He polled his followers—hardly a statistically unbiased group—about restoring Trump’s account, and has restored others just on his own. Tech journalist Casey Newton:

At the risk of stating the obvious, this sort of ad hoc approach to content moderation and community standards is completely unsustainable. It does not scale beyond a handful of the most prominent accounts on the service. And, most worryingly, it is not based on any clear principles: Musk is leading trust and safety at Twitter the same way he is leading product and hiring—by whim.

And this is Twitter’s failure mode. All those tweets you’ve seen bitching about how a big problem with Mastodon is that you might choose an “instance” that ends up being run by an anti-woke edgelord tinpot dictator? That’s Twitter now.

Oh, you say the need for advertisers will help rein in Musk’s worst impulses, because no sensible advertiser wants to have their “promoted tweets” running in line with alt-right propaganda? Good luck with that: a Twitter that’s only ten or fifteen percent of its original size requires a lot less money to run, and Musk’s been clear he aims to reduce the company’s dependency on advertising income.

And those remaining thousand employees or so aren’t going to push back the way we saw happen in some tech companies a year or two ago. The shakeout isn’t just in progress, it’s almost over. The ones left either can’t afford to leave or subscribe to Musk’s worldview. Anyone who joins Twitter under his leadership will have done so knowing what that worldview is.

The “liberal bias of big tech” has always been a phantasm. Silicon Valley has always had a strong libertarian bent to it, from the right-of-center Hoover think tank at Stanford University to the military/aerospace roots that long predate the 1990s dotcom boom. While many SV libertarians are socially liberal, not all are, and a few of the most prominent conservatives came out of the “PayPal Mafia”: Musk, the openly anti-democratic Peter Thiel, and VC David Sacks, who co-wrote a book called The Diversity Myth with Thiel a couple of decades ago. Along with professional idiot Jason Calacanis, Sacks now advises Musk on how to run Twitter, and the circumstantial evidence suggests they’ve encouraged the performative cruelty Musk’s exhibited in how he’s run things so far.

So here’s the thing. What conservative culture warriors always say they want is the absence of political bias, but time and time again what they mean is bias that explicitly favors them. Everything else, you see, has an innate liberal bias—it’s them against the world, fighting the good fight. They want fairness and balance the way Fox News does. They don’t want an unbiased social media site; what they want is a site with Gab and Parler’s slant, but Twitter’s reach. Now they have it. The product of a social network is content moderation, and Twitter’s new content moderators will be hand-picked by Musk. It’s going to be full of people who won’t object to racism, homophobia, and transphobia as much as object to fighting it, because “free speech”.

If you do believe in the Fox News kind of balance, that I’m wrong about Silicon Valley’s political biases and especially wrong about Twitter’s, this isn’t a failure mode. It’s what you want, or at least what you think you want. It’s clearly what Elon Musk thinks he wants. But for Twitter as we knew it, this is a catastrophic failure. It’s a terminal condition, an unrecoverable crash.

New Twitter will be hostile to anyone queer, or non-white, or slightly to the left of Ronald Reagan. You may be a creator who wants to stay on Twitter to reach your audience, but the audience there will inevitably tilt toward the anti-woke, All Lives Matter, gender critical, Just Asking Questions crowd. If they’re your audience, congratulations, I guess. If they’re not, you have a problem.

I get that, right now, it’s still easy to rationalize staying on Twitter. The alternatives are too confusing, or have questionable terms of service, or don’t have a registered DMCA agent, or have a crappy official app, or have a crappy web interface, or just seem like they’re run out of a college dorm room. We can go down the list and acknowledge most or all of those are great points.

But your favorite bar is under new management, and whether you want to admit it or not, you know damn well what kind of bar they’re making it into. You need to think long and hard about whether you’re okay with that.

When TextMate burst onto the scene in the mid-2000s, it didn’t take aim at Emacs and Vim as much as BBEdit, a Mac-only editor around more than a decade at that point. TextMate offered radically easy ways to create sophisticated new language modules and plugins compared to most editors of the day. Mostly, though, TextMate had Ruby on Rails: David Heinemeier Hansson developed the framework with early versions of the editor, making it almost custom-built for Rails. That gave TextMate a boost working with other server-side frameworks.

Since then, cross-platform editors and IDEs like Microsoft’s Visual Studio Code and JetBrains IDEs have come to dominate the coding world. This is an issue for those of us who want Mac-assed Mac apps. I hung onto TextMate and then the native-but-weird Sublime Text, shifting to Code somewhat reluctantly. Last year, I pounced onto Panic’s new Nova, reviewing it positively shortly after release.

BBEdit is obviously a Mac-assed Mac app, and for reasons I’ll return to, I came back to it years ago for technical writing—but not for coding. (It sometimes seems like BBEdit’s biggest fans are writers.) Some more code-focused users, though, haven’t looked at it in years. With the release of version 14, should they reconsider?

Musty, or battle-tested?

Few editors have been around longer than BBEdit—and few have been as rock-solid. I don’t think I’ve ever lost work. It can even “rescue” never-saved documents you mistakenly close without saving!

Yet, that venerable age has become a double-edged sword. “Looks old” is a dismissal I’ve heard a lot. I’ll be honest: to me, it looks like…a text editor.

It’s information dense, but neither overly busy nor packed with unnecessary bits. (Nearly everything shown here can be turned off, too.) One thing you don’t see? Tabs. Instead, there’s an open documents list in the sidebar. If you end up with a dozen or more files open at once, this approach starts really showing its advantage.

Leaping forward

Here’s something cool:

This editor understands PHP well enough to know that after you type $handler->, it should offer methods from the Handler class as autocomplete options, because it knows $handler is an instance of that class.

This level of introspection used to be the exclusive domain of IDEs, but a couple of years ago, Microsoft introduced the Language Server Protocol for Code, so plugins could offer this functionality. Nova supports LSP natively, and with version 14, so does BBEdit. In addition to smart autocompletion, BBEdit uses language servers for:

• Function parameter help
• Real-time code linting
• Navigating to function definitions and symbol declarations
• Reformatting documents

See the green dot in that screenshot? It’s a dropdown for showing errors and warnings in a file. Individual lines also get their line numbers highlighted and the issues shown by underlines. (The snippet above shows $response with a red underline in two occurrences: the first because that line isn’t complete and so has a syntax error on it; the second because, thanks to the first error, $response isn’t defined yet.)

BBEdit is preconfigured to use many language servers, like Intelephense, out of the box once they’re installed. This can be considerably more complicated in other editors, especially if their LSP support is itself provided by an extension.

A couple of caveats: first, a lot of language servers apparently haven’t been tested with anything but Code, and can get quirky with any other editor. Sometimes BBEdit can work around quirks, but not always. Second, BBEdit doesn’t support all LSP features. For instance, documentation won’t pop up when you hover your pointer over a function or symbol.¹

Other new features

BBEdit 14 now has a “Notebook.” This takes the already-existing “scratchpad” feature (itself unique to BBEdit) a step farther, storing multiple notes as individual sheets within an always-available Notebook window. By default, BBEdit creates notes as Markdown files, but you can change them to other languages. As with any text file, you can create new notes from the clipboard or from selected text, by dragging text, or even from the shell by piping text to bbedit --note.

I haven’t played with the Notebook much yet. It strikes me as the kind of feature you’re either going to rarely use or use all the time, and it’s not clear to me where I’ll fall. I use scratchpads a lot, though, and have a weakness for note-taking apps. I could imagine putting together a package that offered some basic to-do list functionality that might effectively replace TaskPaper, too. It’s not Emacs’s legendary Org mode, but then again, it doesn’t make you learn Emacs.

Beyond that, BBEdit now supports Emmet for HTML and CSS expansion if you install the Node Emmet module; if you make from-scratch HTML pages a lot, this is a big deal. If you’re a Python programmer, BBEdit is now aware of Anaconda/Conda virtual environments out of the box, and lets you switch between them with its shell menu.

Other old features

When I became a full-time technical writer in 2014, I tried a few different editors and settled on BBEdit, even though its Markdown syntax highlighting is…spartan. Why? Because BBEdit is a Swiss Army knife, a Leatherman multi-tool, for text processing. In no particular order, here’s some interesting things BBEdit does that I rarely see in other editors.

• What it lacks in Markdown highlighting, it makes up for in Markdown previewing. You can set custom HTML templates, CSS files, and even processing scripts. (You can do this for HTML files, too, and I suspect for other kinds of plain text markup languages.)
• Many editors have a “fuzzy file open” feature, but BBEdit can open multiple matching files simultaneously. I use this way more often than you might think.
• BBEdit keeps a history of find/replace searches, and lets you save complex grep patterns with names for easy recall. And you have to see its “Multi-File Find” feature to fully appreciate how great it is.
• You can build a “text factory” of multiple actions; it’s like having a simple version of Shortcuts or Automator built right into the editor. You can save them as text filters or use them for batch processing. I have a simple-minded Markdown to BBCode conversion “script” I created this way without writing a line of actual shell script.
• You can “process” lines in a file, searching for duplicates or lines that match specific patterns (including regular expressions), and delete those lines, copy them to the clipboard, or create a new document with them.
• BBEdit can operate on “columns” of tab-separated values, cutting, copying, pasting, and even rearranging them.
• While Git support is mostly (ahem) bare bones, it’s fantastic with file-specific commands like diffs and revision history.
• The “Pattern Playground” is outstanding for constructing complicated regular expressions that work with your documents.
• BBEdit uses Kapeli’s Dash documentation browser if it’s installed.

The Unix Worksheet in BBEdit deserves its own paragraph. Send any line in the worksheet to your shell by tapping Control-Enter, and the output from the shell appears under that line in the worksheet. You can’t run interactive shell programs this way, but for most commands you now have an editable, modifiable history. In my technical writing, I create lots of local branches; I usually use a worksheet to clean them up by running git branch to get a list of them, then adding git branch -d before each one I no longer need. The worksheet is inspired by the long-defunct MPW, but Emacs fans might consider it a cousin of shell mode.

Lastly, another feature of BBEdit worth checking out: the 400-page user manual. Yes, that is what a technical writer would say, but it’s a remarkable boon.

A few missing features

BBEdit has a more “batteries included” approach than most editors, and so needs fewer third-party extensions. But, the integrated managers in Code and Nova make a strong argument for a centralized package index. Sublime Text’s Package Control started as a third-party system, so it’d be possible for someone else to take up the mantle here. The closest BBEdit has is BBEdit Extras, and while it has some good stuff, it’s also got a lot of outdated (and frustratingly undated!) stuff and an awful lot of link rot.

Sublime Text popularized multiple cursors in text editors. BBEdit’s processing commands can do nearly anything these can—honest—but if you’re a multi-cursor junkie, it’ll be an adjustment.

Codeless language modules only set colors for strings, comments, keywords and “predefined names,” along with delineating functions for navigation and folding. CLMs also can’t be used for templating systems like Jinja or EEx that exist as “embedded languages” in HTML. You can write a more powerful language definition in Objective-C—I presume including templating languages, since “PHP in HTML” and “Ruby in HTML” are standard—but that’s a hella big ask.

Back to the future

I’ve long believed that BBEdit’s balance of text processing power with discoverability and ease of use makes it the best tool for “documentation as code"-style technical writing on the market. But at least for me, it hadn’t kept up with the state of the art for coding. With BBEdit 14, this no longer feels true.

So, I’m moving back. I’ve created a new color scheme, SpaceBones, inspired by the default color scheme of Spacemacs. I’ve been working on an up-to-date package for Elixir that comes with an LSP, as well as creating a new set of clippings for PHP 8. My old Editor Actions package may get a reboot. Hopefully, there will be ways to publicize these; I’d love to see a BBEdit-focused project similar to Vim Awesome.²

If you’re already a BBEdit user, version 14 is an essential update. If you’re not—whether you used it years ago but drifted away, or never used it at all—it’s time to give it another look.

BBEdit 14 is $49 new from Bare Bones Software, with upgrade discounts for owners of earlier versions, or from the Mac App Store with a $39/yr annual subscription. You can use BBEdit for free with a more limited feature set. Disclosure: I beta-tested BBEdit 14, and received a free upgrade serial code.

TL;DR: I’m not using it much.

I’m sure my review of Nova made it clear that I wanted to like this editor a lot. In practice, though, it’s felt more like its predecessor Coda and a similar competitor of Coda’s era, Espresso, than like Visual Studio Code or BBEdit: targeted chiefly at web developers mucking about with static websites. (Which, to be fair, is a sizable audience; my website is static, and Nova’s pretty good with it.)

Nova’s built-in smart autocompletion hasn’t proved particularly smart when I’ve been using it, which in some ways makes it more frustrating than not having it at all. Backing it with a language server theoretically improves it, but Nova’s LSP support is fragile and weird. I don’t mind it being somewhat incomplete, but it’s entirely dependent on third parties writing extensions that talk to language servers—which would be fine if they worked. But at least in the languages I use, they don’t. For PHP, there are two wrappers for Intelephense; one just flat out doesn’t start, and the other one makes Nova crash on startup. For Elixir, the elixir-ls extension works in the sense of, you know, not crashing, but mostly what it seems to do is hover huge documentation pages over the screen if the mouse pointer rests over an Elixir keyword. (I have heard Nova’s TypeScript extension is solid, but I haven’t tried it.)

Beyond that, when it comes to the basics of just editing, Nova is…fine? It does the job. But—like Coda and Espresso—it doesn’t have the selection and manipulation chops of higher-power editors. I still have no idea what commands like “Select All in Any Scope” are supposed to do because they’ve never worked. Nova’s clips are useful, but limited compared to the equivalents in BBEdit or Code (or any editor, like Code, that basically adapted TextMate’s snippets).

So, am I going to renew for the $49 annual subscription? I haven’t entirely ruled it out, but, well, it’s not looking good. I’ve been spending much more time back with BBEdit recently…but that’s another article.

At the end of 2010, John Gruber of Daring Fireball wrote in a Macworld column,

The central conceit of the iPad is that it’s a portable computer that does less—and because it does less, what it does do, it does better, more simply, and more elegantly. Apple can only begin phasing out the Mac if and when iOS expands to allow us to do everything we can do on the Mac. It’s the heaviness of the Mac that allows iOS to remain light.

Back then he wrote that long-term (“say, ten years out”), iOS might replace macOS. But in 2020, Apple recommitted to the Mac: the Mac Pro, the return of good keyboards, and—the biggest move yet—a new CPU architecture designed in-house.

Since then, I’ve seen a chorus of pundits, both professional and armchair (hi), push two theories that are either at odds or entwined, depending on how you look at them:

• Surely, a dystopian iOS-like future of only sanctioned App Store purchases lies ahead for the Mac. (Let’s call this the “Hacker News bait” narrative.)
• Surely, the iPad is going to catch up or even surpass the Mac—it already does so many things so well, and it’s only held back from its potential by an OS with artificial limitations.

The Hacker News bait narrative is bullshit. But I’m not sure about that second, sunnier one, either. Apple has been demonstrating a consistent philosophy for over a decade:

• Macs are general purpose computers.
• iPads and iPhones are application consoles, analogous to game consoles.

These have been true from the beginning of each platform. Macs have always been general purpose computers, and iPhones and iPads have never been such.

There’s no intrinsic reason iOS devices had to be consoles; other smartphones like Windows Mobile and PalmOS phones weren’t. We all know that, but we forget that there’s also no intrinsic reason Macs had to be open. Not only was its direct antecedent the Xerox Star considerably more console-like, so was Jef Raskin’s original concept for the Macintosh, which evolved into the Canon Cat. Yes, if the Mac had been positioned as an appliance the way the Star and the Cat were, it would likely have joined them in obscurity—but we say that now with nearly four decades more “common wisdom” about computers. The Cat wasn’t the only early attempt at an application console; the 1990s saw the Sony eVilla and other “Internet appliances.” Those products didn’t fail because the concept was bad; they failed because the technology to support the concept just wasn’t there yet. A decade later, we had small, lightweight touch screens and widespread high-speed wireless data—and internet appliances became possible.

As long as this philosophy on Apple’s part holds—and there’s no evidence that it’s changing—macOS will never be locked down to the degree iOS is, i.e., unable to install non-App Store apps without jailbreaking. But the Venn diagram of “users likely to walk over such a drastic change to the Mac” and “users likely to spend boggling amounts of money on Apple hardware” is close to a perfect circle. Apple would have to not only make up the lost hardware revenue in App Store revenue but beat it. You need 30% of a hell of a lot of apps to make up for a single lost 16-inch MacBook Pro sale, let alone a Mac Pro. Even if it was just four or five percent of users—and I think that’s extremely optimistic—that’s millions of lost unit sales, and likely forgoing entire markets the Mac currently has a meaningful presence in. There’s just no business case for such a move. Beyond that, given all the radical changes Apple made to the Mac in 2020, it feels like that was the “now or never” moment. If M1 Macs and macOS Big Sur didn’t lock us into an App Store-only world, it’s pretty unlikely macOS Pismo Beach or whatever is going to.

But that brings us to the second point. Is this the year when the iPad does get to do everything, not just most things, the Mac does? Will we be able to run macOS apps on M1 iPad Pros the way we can run iOS apps on M1 Macs?

I do think Final Cut and Logic will come to the iPad eventually in some form. But so far, macOS has remained a general purpose OS, and iOS has remained a console OS—and I don’t think that’s changing soon. I just don’t. I’m doubtful that Apple has any interest in getting an Xcode-like iPadOS development going, and doubtful they plan to “open up” iOS any more than they must for technical, market, or regulatory reasons.

Yet on an infinite timescale, this dichotomy can’t hold. It may be a minority of people who truly can’t do their work on the iPad, as opposed to just kvetching that they can’t do it the same way as they do on a Mac or a PC. But that minority is there, and they matter.¹ So the question is what happens to break it and when. I’m expecting iPadOS 15 to have some major UI changes, possibly even the first tiling window manager designed for humans. My pie-in-the-sky guess is that a new operating system replacing both macOS and iPadOS is already underway. Its foundations are Swift and SwiftUI, and macOS Big Sur and iPadOS 15 are early bits of scaffolding. The Mac gets lighter; iOS gets heavier. But they’re not meeting in the middle yet.