Last week one of the better developers who historically has made “Mac-assed Mac apps” announced that their upcoming major update will no longer be a “pure” Mac app. I’m talking about AgileBits regarding the upcoming 1Password 8. This was alongside the release of an early access build, and led to a major storm of users getting up in arms against their choices (for the record, the same week people got up in arms about CSAM scanning coming soon on Apple’s operating systems). I, too, was quite annoyed by this choice from AgileBits, still am somewhat, and certainly have been active in their forums alongside fellow Mac 1Password users regarding this. But I’ve taken the past week plus to reflect on all of this, and yes, have now even begun running the early access build of 1Password 8 full-time. The decision made by AgileBits is not purely one they’ve made, it is a whole direction some desktop apps are going. 1Password will not be the first, nor the last, Mac app to shed its full Mac-ness. This is sad, but has already begun even within my daily usage.

This post is not mainly to talk about 1Password 8, but to lay out the sheer number of species of apps that today make up what folks can use on the Mac. It is quite the hodgepodge of technologies, and on any given day I likely use at least 2/3, if not all, of these. I’ll try to not get too technical, except with names of these technologies. My goal is to just lay out, for the record mostly, just how many different ways there are now to make apps that run on macOS.

AppKit

Years ago every app on the Mac was built using Apple’s interface framework for the Mac, AppKit. Today many apps, including a bunch of Apple’s, still use it. I think when people talk about “Mac-assed Mac apps” they tend to be referring to this kind of app, built with the same quality Apple once had, and a few developers still maintain. Perhaps BBEdit remains as today’s most prevalent 3rd-party app of this caliber I use, especially with the news regarding 1Password.

As a user these are the apps that feel most “at home” on the Mac. If they’re document-based apps, the document windows and interactions (like for saving and opening) all feel “right”, at least for longtime Mac users. There are increasingly few ways to truly tell a Mac app of this sort apart from some, but another clear example are that parts of the app use interface elements you find in some of the apps built into macOS. These apps are “pure” Mac apps, since no other platform can run them.

UIKit

The iPhone and iPad are not the Mac. That is something everyone can agree on. Different sizes, but also an entirely different model for how we interact with the devices. Touch, versus mouse pointer. Quite a different thing. So Apple set out to create a different technology for developers on this platform back in the late oughts: UIKit. For those who started developing on the Mac, there are many similarities, but also it is different. I know, from experience with both as a developer. Over the past decade plus the developer community on iOS (since iPadOS, watchOS, and tvOS are all basically iOS I’ll just say iOS going forward in this post) has far outnumbered that of the Mac. So Apple wanted to make it easier for iOS app developers to get on the Mac.

Their attempt at this is a technology called Catalyst. With minimal effort, at first it is just one checkbox in Xcode (the app many developers use to write apps for Apple’s ecosystem, myself included), you can get your iOS app running on macOS. Now, to make a decent Mac app takes more work. But most of your work for iOS translates over quite fairly. A number of Apple’s own apps use this technology, and they’ve added more over the years. Most notably Messages starting in Big Sur (ever wonder why it gained many formerly iOS-only features?), but also Podcasts, News, Voice Memos, Home, and more. There was even an old rumor at the time that Photos used a precursor to what we now know as Catalyst from its inception.

But these apps don’t always feel that Mac-like. Some still have, or did until Big Sur, actual iOS-looking interface elements. A lot of these apps are single-window apps, because until recently on the iPad, that is all iOS app had. Maybe an import window is essentially an iOS sheet, not a separate window like something like iMovie uses. These apps, while increasing in both number and feeling more natural on the Mac, are still a separate species. They may be, you could say, the children of AppKit apps.

With the arrival of Apple’s transition to Apple Silicon came yet another incarnation of UIKit on macOS, specific to this architecture. These Macs can run iOS apps natively. That is, they can run apps built for iOS, unmodified. The Mac App Store on these devices literally has tabs to switch you over to the iOS App Store. I have a handful such apps. One of these (the weather app Hello Weather) I effectively use daily as its widget is in Notification Center. Developers can choose to allow installation of their iOS apps on Apple Silicon Macs or not. Many large names chose not to. Apple has not, as of Monterey, shipped any of their iOS apps on the Mac like this, and though I wouldn’t put it past them to do this someday (their care for user experience and interface is severely waning) it is unlikely, due to Catalyst.

iOS apps running on macOS are even less normal feeling than Catalyst apps. They work, and I do appreciate being able to run them, but it is very clear that they are not Mac apps. Windows are not resizable, apart from switch orientation. Interacting with the apps can be strange, and some apps require a “Touch Alternatives” mode that changes the behavior of the trackpad and keyboard to mimic interacting with a handheld device. I wonder if the iPadOS mouse pointer will ever make its way to the Mac (I actually like it quite a bit, though have barely ever used it), and if it does being used in these apps first may be appreciated. But, Apple Silicon is the dawn of an era when any iOS app can, technically, run on the Mac. These are a different, yet related, species, but one that truly dwarfs AppKit apps in sheer numbers.

SwiftUI

In 2014 at Apple’s WWDC conference the “one more thing” shocked me, and many others. To make it way simpler than it truly is, they basically said “hey, here is a brand new programming language that will eventually replace what you currently use.” That programming language is Swift. I, at least, was not expecting that, and as such remember where I was when hearing that. A couple years later, they came out with SwiftUI as an entirely new interface design library built in Swift. Over the years they’ve been improving SwiftUI.

The goal of SwiftUI is to create one interface library that appropriately targets whatever platform it is built for, with the same code. So for example, an alert box would look like an iOS alert on a phone, but a Mac alert on a Mac, with no extra work by the developer. This is a lofty goal, and one I personally am excited about. In a way, it is a single library to spiritually have end user interface like both AppKit and UIKit depending on the device. But it has been a few years, and that developers like AgileBits tried using it for their macOS app, and then abandoned the project since they’d have had to redo lots of work for the Mac, is telling. The one slight hope with 1Password 8 is that the iOS app is SwiftUI, so perhaps 1Password 9 on macOS will return to a native interface framework once SwiftUI has further matured.

Given the goal of SwiftUI, it is basically impossible to know what apps you may use are using it or not, unless the developer tells you. I’m certain that some areas of macOS and iOS are using it, but am not entirely sure which areas. I heard once that the Dock team was adopting it, so maybe the macOS Dock is using SwiftUI, but I’m really not sure.

Web Apps

A few apps that I use are completely just web apps. These you can run in a web browser, but can also use a tool like Coherence to wrap them up like a Mac app. As such, these are really just mini web browsers for specific sites. Perhaps the most common of these are the suite of tools from Google where developers have even written purpose-built apps, but actually my two most common are Airtable and AnyList. Basically these are separate web browsers, but since they end up as apps, I include them here.

Apps like this are very easy to tell, largely because you may have intentionally created them, but also as they’re basically just websites. They aren’t at all Mac-like, but are convenient to have so that you aren’t overloading your web browser of choice with web app tabs.

Electron

The last species of app on my Mac (that comes to mind right now) is Electron. This is a Chromium framework used increasingly by developers to create cross-platform apps. Being Chromium, it is inherently web technology. So these apps are essentially websites. But unlike web apps, they can appear more native if done well, and are all self-contained, so you aren’t actually loading code from a remote server.

The impetus of this post is one example, 1Password 8. But part of why I have come around to running the early access full-time within a week of its release (historically I have run 1Password betas), despite being saddened that it uses Electron, is recognizing how completely I am already using Electron apps every single day. As a web developer, I use Local to run whole development copies of WordPress sites on my Mac for development and testing purposes. Given scripting, that app is actually running all the time. For the past few years my code editor of choice for web development (and some others as time goes on) is Visual Studio Code. This Microsoft-built open source editor is using Electron, and since I use it so much (and just never really manually quit apps often on my Mac) it is mostly always running. So, combined with the power of a top of the line Apple Silicon Mac, maybe Electron isn’t too bad. Note, though, for the security-conscious, that another benefit of how 1Password 8 uses Electron is that, unlike Visual Studio Code, it is only the interface, the core of the app is a separate beast that is kept segregated as much as they can from Electron. I personally regularly see Messages use more resources than 1Password 8, or any other Electron app I use.

What does this mean?

The macOS platform no longer is home to just its own species of app. That ship has long since sailed. This may be sad for longtime Mac users, it is for me, but it is simply the reality we live in. To summarize, the species I’ve identified italicized above are:

• AppKit
• UIKit - Catalyst
• UIKit - Native
• SwiftUI
• Web Apps
• Electron

There may be more, too, that I simply haven’t thought of at the moment of this writing.

Each species has its own degree of feeling “at home” on the Mac. Each has its own advantages and disadvantages for users and developers alike. Together they all form what is today’s landscape of Mac apps. Don’t get me wrong, I am sad at more and more apps using web technologies, and what we still term “native” apps (AppKit, really) fading. Even many of Apple’s apps are now built in Catalyst (Mail will join their ranks in Monterey), which is at least a species I’m more comfortable with on my Mac than web technologies. But we cannot deny the reality that these apps of different species are valid apps on our Macs. We’re all using them, because they’re necessary for whatever they do for our lives. 1Password 8 is not the first such app forcing us to use a different species, nor will it be the last. Heck, part of what has drawn me to use the early access is its unification of browser extensions, though I am surprised the new-style (which is shipped in the Mac App Store) Safari extension didn’t seem to work with 1Password 7. That is another species, as Safari extension development supports extensions built for Google Chrome, not just Safari’s own format.

So we may be sad at this direction, but should we really be as annoyed about it as the backlash against 1Password 8 makes it seem? My thinking, after this past week especially, is that we shouldn’t be as annoyed. On the one hand apps like 1Password, Local, and Visual Studio Code are on multiple platforms, and as tech advances it may be inevitable that more apps go that route. In that case, us Mac users will not be alone, these apps won’t be quite “at home” on Windows or Linux either. The only sad thing there is how few developers try to make something that feels decent on any platform, rather than just feel like a web app. On the other hand, Apple may share some of this blame given SwiftUI’s (and frankly even Catalyst’s) slow progression. I do hope that there is a future where at least in Apple’s ecosystem one app can run and feel “at home” on everything from an Apple Watch to a Mac Pro. But we aren’t there yet. For now, the Mac may be the proving ground of an assortment of species of apps, and be this hodgepodge of technologies. Yes, this is a bit strange. It certainly may feel like that. But I’m not sure it is as much of a devil as some people think. Something marvelous may come from all this. The challenge is that we’re not too far down the road yet.

It is certainly a messy time to be running Mac apps, if you think about how many species are coexisting. That I cannot argue against. I only question, because I’m far from certain myself, how problematic this may actually be in the long run.