If there is one word I would use to describe what makes an Apple-like experience, it’s “cohesion”. Any Apple enthusiast is aware of the company’s Human Interface Guidelines (HIG). The Macintosh has had one since 1984. iOS has had one since the launch of the App Store in 2008. Even WatchOS and tvOS have their own versions. Apple has had opinions about building cohesive user experiences for as long as Apple has been building user experiences. Take this excerpt about menu titles as an example:

Use text, not icons, for menu titles. Only menu bar extras use icons to represent menus. See Menu Bar Extras. It’s also not acceptable to use a mixture of text and icons in menu titles.

Here’s another from iOS:

Don’t include multisegment breadcrumb paths. The back button always performs a single action—returning to the previous screen. If you think people might get lost without the full path to the current screen, consider flattening your app’s hierarchy.

Strong direction with phrasing like “don’t” and “not acceptable” illustrate the extent to which Apple cares deeply about how applications (or apps) work cohesively on their respective platforms. At least, I think they still care. What gives me doubt is the rollout of Catalyst, the methodology released by Apple to more easily port iOS apps to Mac OS. My concerns with the framework have stemmed from a fear that Catalyst apps would be incongruous ports of iOS apps with a thin Mac veneer.

Based on early reviews of Catalina, the first version of Mac OS to ship with Catalyst support, experiences with Catalyst apps have not been good.

Incongruous ports with cheap veneers are nothing new to Mac users. While not every port is terrible, there’s a long history of mediocre Mac software written in so-called “write once” solutions from Java to Electron. What makes Catalyst different is that it’s a “write once” solution from Apple. Incongruous solutions from third parties is disappointing, but an incongruous solution from Apple itself is worrisome.

The first cause of concern was with the proto-Catalyst apps found in Mojave — News, HomeKit, Stocks, and Voice Memos. All of them clearly ports of their iOS counterparts, all of which incongruous (not to mention mediocre) to varying degrees — limited context click support, no ability to read News articles in separate windows or tabs, etc… The one hope was that these apps were effectively a starting point to a much larger and more cohesive solution to come.

Long time code spelunker Steve Troughton-Smith also saw signs of encouragement, even with capabilities in those early apps. Back in March he Tweeted that, with some additional effort, a Mac-like experience was achievable with a “UIKit Mac app” (his term for Catalyst before the framework had an official name.)

His tweet:

With just a little care and attention, suddenly your UIKit Mac app no longer feels like a foreign invader. It’ll fully be within developers’ power to make great Mac apps w/ UIKit when macOS 10.15 debuts @ WWDC. For many devs, UIKit will be first choice when considering a Mac app

While Steve’s outlook was optimistic, his phrasing gave me pause.

Here’s what I replied:

While Steve provides some hope for UIKit based Mac apps, I would argue that any additional attention required for fundamental Mac-like experience and consistency is too much.

While in hindsight I think “any additional attention” may have been too strong, I think the sentiment of my criticism back then was spot on for what we are seeing today. Developers using first party tools from Apple shouldn’t have to swim upstream to build cohesive Mac versions of their apps. I am not saying that the existence of any incongruous Catalyst ports is worrisome — incongruous ports are inevitable and Catalyst is an opportunity to make them better — what’s worrisome is that incongruity seems to be the default with Catalyst.

Look no further than Apple’s own Catalyst ports. Developers have enjoyed a variety of good first party examples on both Mac OS and iOS. Mail, TextEdit, Preview, Notes serve as examples of what good cohesive apps on those platforms should look like. Outside of maybe the Podcasts app, Apple made Catalyst apps feel like ports.

The crux of the issue in my mind is that iOS and Mac OS are so fundamentally different that the whole notion of getting a cohesive experience through porting apps with minimal effort becomes absurd. The problem goes beyond touch vs pointer UX into how apps exist and interact within their wider OSes. While both Mac OS and iOS are easy to use, their ease stem from very different conventions.

The more complicated Mac builds ease almost entirely through cohesion. Wherever possible, Mac applications are expected to share the same shortcuts, controls, windowing behavior, etc… so users can immediately find their bearings regardless of the application. This also means that several applications existing in the same space largely share the same visual and UX language. Having Finder, Safari, BBEdit and Transmit open on the same desktop looks and feels natural.

By comparison, the bulk of iOS’s simplicity stems from a single app paradigm. Tap an icon on the home screen to enter an app that takes over the entire user experience until exited. Cohesion exists and is still important, but its surface area is much smaller because most iOS users only ever see and use a single app at a time. For better and worse, the single app paradigm allows for more diverse conventions within apps. Having different conventions for doing the same thing across multiple full screen apps is not an issue because users only have to ever deal with one of those conventions at a given time. That innocuous diversity becomes incongruous once those same apps have to live side-by-side¹.

On the surface, the closest thing to iOS on the desktop was Apple’s At Ease, but At Ease was a relatively thin veneer forced on poor school kids like yours truly. Opening an application from At Ease brought the user back to the Mac user experience. As such, there were no At Ease apps. I think a better comparison to the challenges Apple faces with bringing iOS apps to the Mac is Microsoft’s transition from DOS to Windows.

As opposed to Apple, which made a clean break from ProDOS when creating the Macintosh, Microsoft built Windows on top of DOS. DOS is nothing like iOS, but I’d wager that bringing DOS programs into the Windows interface came with similar challenges when it came to platform cohesion. Like iOS, DOS (like other CLIs) was more-or-less a single app experience. A command was entered to start a program, which took over the entire user experience until exited. DOS programs either had no graphical user interfaces, or entirely bespoke ones. Trying to create a cohesive experience in Windows took (and some would argue is still taking) Microsoft years to accomplish.

With Touch, Apple again made a clean break when creating iOS. I still think that was the right move in that the touch experience is more cohesive on iOS than on Windows 10. Furthermore, I suspect adding pointer support to a touch interface is easier than doing the opposite so it makes sense to port iOS apps to the Mac rather than vice versa. That said, building a cohesive Mac application from an iOS app requires so much more than adding pointer support along with the minimal desktop trimmings that Catalyst seems to support, let alone enforce.

The counter argument to this concern is that the Mac is stuck in the past and needs to evolve, and that any criticism of Catalyst is akin to fans of classic Mac OS criticizing Mac OS X for being new and different. Putting aside that early releases of Mac OS X deserved criticism, I think the difference is that even those early Mac OS X versions were about building a cohesive new platform, even if it meant replacing conventions of classic Mac OS. A die-hard fan of classic Mac OS could argue that Mac OS X wasn’t Mac-like, but they’d be hard pressed to argue that it wasn’t Apple-like. I am not worried apps made with Catalyst can’t be Mac-like. I am worried that Catalyst, incongruous as it is by default, isn’t Apple-like.