Electron and How Cross-Platform Apps Will Save the Mac
Last week, Slack announced the availability of a much anticipated feature; the ability to resize not one, but both sidebars in Slack.
If you are wondering, “Wasn’t resizing the sidebar a standard feature in apps since the 90s?”, you aren’t alone.
Like most of Slack’s quality of life feature announcements, it didn’t take long for folks to pile-on and get their shot in; the snarkiest of which came from John Gruber of Daring Fireball:
I’m reminded of Alan Kay’s comment regarding the original Macintosh, that it was “the first personal computer worth criticizing”. Sometimes when people ask me what’s wrong with non-native Mac apps, I feel the opposite: they’re so wrong and so bad they’re not even worth criticizing. Resizeable sidebars, for chrissake.
I read Daring Fireball daily, I listen to the podcasts, and I advertise my company, Kolide, on both mediums regularly. I am a fan.
That’s why I say, with all the respect in the world John, you are missing the whole forest as you fret about the Pantone of several leaves on a single tree. Slack is a good app worthy of your criticism, but more importantly, can show us how macOS and iPadOS may evolve over the next few years. I think the future of the Mac is brighter than you think.
Slack - Built On Electron
Gruber’s criticism of Slack (or rather his criticism that Slack is not worthy of criticism) is based in its non-native appearance and behavior.
The technical reason Slack does not feel like a Mac app is that it is written in Electron, a popular framework where engineers can approach app development using the same toolset and languages they would use building a web application in the browser.
While there are obvious benefits to a web application developer, the prevailing theory is user experience suffers.
Traditional web apps — like Gmail or Github — are not expected to look like native apps in your OS. That would be like expecting every dinner guest in your home to know that the dessert fork wasn’t to be used during the main course. But Gruber’s beef isn’t with them, it’s with the Electron apps. They don’t just visit your house for dinner, they become your messy roommate — and like most new roommates, they don’t always heed the carefully written house rules or well-understood etiquette. To restate Gruber’s point — It’s not even worth trying to teach them the most efficient way to load the dishwasher; they can’t be bothered to put their dirty dishes in the sink for chrissake.
I don’t want to put words in John’s mouth, but to say he isn’t a fan of Electron is putting it lightly. Here is an excerpt from his article entitled Electron and the Decline of Native Apps:
…Electron is without question a scourge. I think the Mac will prove more resilient than Windows, because the Mac is the platform that attracts people who care. But I worry.
My problem with his overall criticism — a criticism that many share — is that he implies Electron is a tradeoff. The developer gives up the prospect of ever creating a great app so that they can build the app faster. This is only true if you subscribe to the notion that only native apps can be great.
Before I attempt to convince you, let us dispense with the argument that Electron should be used to create and ship macOS-only apps because it is easier for the developer. No way. Today’s Xcode is a good IDE and the Swift language is a delight compared to byzantine Objective C. And finally, learning the tools and languages are easier than ever thanks to the friendly and carefully written guides by the dedicated Developer Relations team at Apple. If you want to make a great macOS app, read the docs, build with Apple’s tools, and follow the Human Interface Guidelines. If you don’t want to build them that way, that’s okay, but you will find no adequate armor for you to wear in this essay.¹
Second, I want to acknowledge that I am currently not living with a disability that impacts my ability to use a computer. While I have built accessibility into a few web apps of mine, I have to admit I have never tried to use a popular Electron app through the eyes of someone who relies on accessibility features. They may be good; they may be terrible. While I cannot speak intelligently about this issue, I hope to see others who have more experience chime in and share their thoughts.
My argument for building macOS apps in tools such as Electron, is that it’s a means to an end, an end that benefits the user, not the developer. This end is an interface that emphasizes cross platform consistency, not nativeness.
Cross Platform Consistency
In application development, the term Cross Platform Consistency describes an app that looks and behaves the same across all available platforms. This should not be taken literally; each platform has its own distinct UI surfaces and human input modalities that require apps to work differently to convey the same information or enable the same feature.
With that stated, many feel the best approach is to take this to the extreme, only building apps that either are, or at least feel native to their respective platforms. Counter-intuitively though, this approach often begets more confusion in the end-users who use your app. To understand why, let’s consider which apps we use are cross-platform to begin with.
If you take stock in the cross-platform apps you use today, you may notice some commonalities. In my macOS Dock for instance, I spy Slack, 1Password, Apple Music, Apple TV, and VSCode. Except for VSCode (which we will talk about later) all of these apps have one thing in common, they are backed by a monthly or annual subscription.
Cross Platform Consistency is an essential element to almost all apps that offer a subscription based business model. Customers who pay for a subscription, which is in essence a service, want access to that service in as many situations as that service provider will bear. It makes sense that the perceived value of the service goes up the more opportunities the buyer has to use it.
Users of services disguised as apps think about them in their totality. If someone asks me a question about a Spotify feature, I visualize a generic amalgamation of Spotify’s branding and UI across all the platforms where I use it. I don’t compartmentalize in my mind Spotify for macOS vs Spotify in my web browser; there’s no point as they might as well be the same thing. This is good. Any major differences in how that app looks or behaves on different platforms create a combinatorial explosion of new things to learn to achieve the same end. In this case, consistency is more beneficial than nativeness.
Ice Water In Hell
Cross Platform Consistency has been a component of subscription service apps since they’ve existed. In the 90s, America Online had clients for Windows and MacOS. These clients may have had some native controls on the fringes of the UI window, but the creamy center was unapologetically and regretfully AOL.
Moving forward to the 2000s, we arrive at the era of iTunes for Windows and the iTunes Music Store — an app where Apple made no attempt to make it look like a traditional Windows program.
But, even this example is not a perfect. Back then, individuals experienced most apps through the lens of a single platform. If they used iTunes or AOL, they were using it on either macOS and Windows, not both.²
In the next decade things changed. At WWDC in 2011 during the iCloud announcement, Steve Jobs famously busted the Mac and PC down from the rank of digital hub for your digital life to just another device. In what would be his final keynote, he acknowledged iCloud was needed because average people now for the first time ever, had multiple portable devices that could access content and data from the Internet. Users of these post-PC devices expected the content they purchased and the data they generated to be available to them everywhere; without thought or effort.
If you rewatch that keynote, it’s important to remember the problems iCloud solved weren’t exactly hard for customers to articulate— at the time, users were just about fed up with the constant syncing hassles.³
However, right after Steve defines the problem to be solved, he says something very prescient:
“Now some people think the cloud is just a Hard Disk in the sky, right? And you take a bunch of stuff, and you put it in your Dropbox, or your iDisk, or whatever, and it transfers it up to the Cloud, and you can drag whatever you want back out on your other devices. We think it is way more than that.”
The bolded emphasis is mine; emphasized because of Steve’s subsequent demos of iCloud apps like iBooks and Photos demonstrated a new revelation. These new cross-platform Cloud-centric apps not only showed what the crowd asked for — data consistency — they gave them what they actually wanted — consistency of experience.
Messages.app
Messages.app was the first real Apple developed macOS app that began its life on the iPhone.⁴
Introduced in Mountain Lion in 2012, Messages was the first of many apps that demonstrated the synergistic benefits when you fully participate in Apple’s hardware ecosystem — a competitive advantage not accessible to anyone else at the time.
The Messages experience may originate on the iPhone, but on the Mac as an app it feels native. The sidebar resizes, selecting a conversation auto-focuses the text input in the main chat window, and the keyboard navigation works identically to other native Mac experiences.
However as I write this in 2020, this native consistency comes at the cost of feature consistency. As an example, here is a short list of things I cannot do in an iMessage conversation on my Mac that are possible on the iPad and iPhone:
- Tap/Click a message and add a reaction
- Record and send an Animoji message
- Access, download, or buy any of the Messages Apps (stickers, gifs, Apple Pay requests, and any of the other fun things available on that platform)
Looking beyond the things that are missing, there is also a lack of consistency in the behavior of features that are available on all three platforms. For example, the search capability available on macOS is a complete joke in both quality and performance when compared to the iPhone and iPad versions. It’s not even close.
Messages on macOS judged without awareness of its iOS siblings is a serviceable native app — no less flawed than the native app exemplars we enjoyed from the halcyon days of yore. With that said though, we know the terrible truth: messages is a marginal app on macOS, not because it lacks data uniformity, or nativeness, but because it lacks experiential uniformity.
Slack on the other hand, does not suffer from these major differences. Sure, sometimes a new feature lands in the Mac app first, but the gap is quickly closed days later; not so with Messages on the Mac which seems perpetually two years behind its iOS siblings.
Is this a fair fight? No. Slack’s search feature is fast and works uniformly cross-platform because it talks to a server that can see all your messages in the clear. Messages.app on the other hand, backed by a service where even Apple cannot read the content of your messages, must do all the heavy lifting directly on your device. I value the privacy Apple provides, but the cost in functionality is nevertheless real and painful.
VSCode.app
In Stack Overflows’ 2019 annual survey, Microsoft’s VSCode Development environment ranked above all other tools by a wide margin. While StackOverflow’s data does not break down the respondents by preferred operating system, we can safely assume VSCode ranks in the top 3 on macOS.
While popularity is not an accurate measure of quality, one has to at least acknowledge VSCode’s ascension to number one is a remarkable achievement — especially in the face of Microsoft’s previously terrible reputation in the IDE market.
At my endpoint security company, Kolide, we have to write software to gather data from macOS, Windows, and Linux devices. We use native APIs to obtain this data, so it should be no surprise that I am constantly swivel-chairing between two or three different laptops depending on which OS will be the focus of my efforts.
The key to making this not hellish is to locate and embrace as much consistency as I can conjure up. VSCode’s cross-platform consistency allows me to tap into the benefit of muscle memory I’ve spent years etching into my very being. Before Electron made this feasible, this consistency was only possible with terminal based editors like Vim and Emacs.
Remember when I said VSCode was the only Electron app in my Dock that didn’t come with a subscription service? This isn’t going to be true for much longer. This year, Github (acquired by Microsoft in 2018) announced Code Spaces, a service that brings a full-featured IDE to the Github web app.
While the browser-based editor is clearly VSCode (a feat made only possible by VSCodes’ Electron heritage) the most exciting revelation comes directly from the Product Manager in charge:
Once released, Codespaces will mark the first time developing software will become practical on the iPad. More importantly though, for me, it’s the consistency we have from Electron that form the basis of this excitement. I know the years of hard won experience will translate to this new environment; the wind will be at my back.
Compare this to Nova, Panic’s love-letter to macOS code editors (not yet released). This editor not only looks gorgeous but you just know Panic is going to sweat every detail and make an app that not only feels native but raises the bar for all others.
It doesn’t matter though. When released, Nova might be a great macOS app; but just like how Electron could never be used to create Nova, XCode could never be used to create the cross-platform consistency I need. The mere notion I might use the iPad to do my work knocks it out of contention. It’s that important.
The Future of macOS
Gruber frets about the future of the Mac in Electron and the Decline of Native Apps.
In some ways, the worst thing that ever happened to the Mac is that it got so much more popular a decade ago. In theory, that should have been nothing but good news for the platform — more users means more attention from developers. The more Mac users there are, the more Mac apps we should see. The problem is, the users who really care about good native apps — users who know HIG violations when they see them, who care about performance, who care about Mac apps being right — were mostly already on the Mac. A lot of newer Mac users either don’t know or don’t care about what makes for a good Mac app.
Where he sees Electron as a potential existential threat to the Mac — a symptom of its popularity; I see something different unfolding.
Once Github’s Codespaces product launches, I don’t need to use my Mac everyday, and I’m not alone.
In the next three to five years, the iPad is poised to become the car Steve Jobs talked about — a generalized device suitable for the average person’s daily life, work, and home. Despite Apple’s efforts to keep the iPad locked-down, subscription based Electron apps and regular web apps are finding ways to exist and are slowly replacing the Mac and PC-only workloads one-by-one. Accessories like the iPad Magic Keyboard with its built in trackpad only close the gap further.
Paraphrasing Gruber, iOS enjoys the benefits of simplicity and ease of use, because the Mac absorbs all of the complexity that must exist in the ecosystem. I believe iPadOS will soon be the platform that absorbs a different kind of complexity — multi-platform services disguised as apps.
If this trend continues, Gruber may actually get what he wants — macOS will become the mighty truck, a highly specialized device featuring heavy-duty, battle-tested apps for the most discerning of users. These are the users that recognize the value in great software and are willing to pay hundreds of dollars for it. In short, they don’t want it everywhere, they want it right.
Bringing this inevitable future analogy to life, I imagine Gruber peering over the steering wheel of his sturdy 16-core Mac(k) Truck watching the daily iPad commuters swerving erratically around him. The view out his windshield is perfectly clear, save for the reflection of his own smile.⁵
1. ^ Confusingly at WWDC 2019, Apple announced two different technologies, Catalyst and SwiftUI. Both were billed as excellent solutions for developing multi-platform apps. Despite Apple’s protestations, Catalyst feels like a transitional technology that helps iOS developers easily transition their apps to to the Mac. SwiftUI on the other hand, feels like the future of building declarative multi-platform UIs in Apple’s ecosystem. With that said, both technologies are in their infancy and are marred by bugs. If you want to build an app that a seasoned Mac veteran would consider native, it’s best to avoid both of these technologies for now in favor of AppKit. I am hoping this caveat will not be needed after WWDC 2020 kicks off in a few days.
2. ^ If you know your Apple history, you may recall iTunes also had a short lived stint on MacOS 9 in the early 2000s. The OS X brushed metal interface juxtaposed with the Platinum theme looked absolutely alien. If you were still lingering on OS 9, launching iTunes was like Apple putting smelling salts under your nose; a last ditch effort to wake you up so you could get the hell out of the burning building in time; the roof was about to cave-in.
3. ^ When the iPad was introduced in 2010, the typical Apple devotee suddenly wrestled with the unique problems associated with owning three internet-connected Apple devices. Within months of release, the syncing hassles were so well-known that Steve Jobs actually addressed them during the Q&A portion of his final All Things D Interview in 2010. With the benefit of hindsight of iCloud’s impending launch, it’s fun to watch Steve squirm as he attempts to address the complaints without revealing the definitive solution.
4. ^ I use this vague word “real” for two reasons:
First, Mac OS X Lion featured skeuomorphic iOS ports of the Address Book and Facetime a full year before Messages was released on the Mac. I ignore these native apps because they don’t steelman Gruber’s argument. Those apps were a mess visually and functionally. They only deserve our pity, not discussion. Luckily they’ve improved considerably since their introduction.
Second, it’s technically incorrect to imply Messages was a new app. It was actually the direct successor to iChat, which was not used for sending and receiving iMessages, but was instead a multi-service instant messaging client. For a time the original iChat functionality remained buried in the Messages.app; today however, like the services it once supported, those features are long gone.
5. ^ No snark intended here. I truly think Gruber will be happier as the Mac regains its former counter-culture luster. I also think all of the devoted people and indie dev shops who made great Mac apps in the early 2000s will stick around and continue to build great software for the platform; they know the audience that appreciates their efforts cannot go anywhere else.
