Where Mac Catalyst Falls Short ⇥ highcaffeinecontent.com
Mac Catalyst is in a great place; it has improved substantially every year since its introduction, and for most developers it is by far the best way to build great Mac-like Universal apps that run across iPhone, iPad and Mac. Its hybrid nature allows a developer to pick and choose which elements of UIKit, SwiftUI, and AppKit they need to achieve the experience they’re looking for, or combine them all for the best of both worlds. It clearly has a lot of traction inside Apple’s product teams, as it’s become the enabling technology for Messages, Maps, Podcasts, Find My, Playgrounds, Books, Voice Memos, Stocks, Home, and News. Paired with SwiftUI, it’s rapidly becoming the defacto standard for new Mac apps on the App Store, for better or for worse — all the more reason that the remaining rough edges be given priority. Each one of the remaining barriers just gives a developer reason to avoid trying for that extra mile, relying on the iOS behavior they know and that works.
Troughton-Smith has been among the most vocal supporters of Catalyst so I am not too surprised to see this mostly positive framing of its shortcomings. I do not mean that as a slight, or in a passive-aggressive way: it is refreshing to hear from a developer about a more successful cross-platform framework than the genre has generally produced. But, still, it is missing a lot:
The biggest glaring hole in UIKit on macOS is its handling of document-based apps. There are many reasons it falls flat, but let’s start with the basics: Xcode’s ‘Document App’ template for iOS crashes on launch when you add Mac Catalyst support, because it lacks the basic entitlements for opening files. Even after fixing that, and adding the requisite document types in its Info plist, actually trying to open a file will send the document browser into an endless loop of showing the file picker. This alone might be the instant death of a potential document-based app, because even experienced developers will suddenly be lost at sea trying to patch the built-in template to run as expected.
I suppose this is more of an Xcode problem than a purely Catalyst problem, but it is clear through Troughton-Smith’s many examples that document-based apps simply are not yet front of mind for Apple’s vision for Catalyst.
I still cannot point to a Catalyst app that I love, by which I mean an app I love that happens to be built with Catalyst. The best I can say is that Maps and Messages in Monterey feel fine most of the time and, if I were not told, I would not know they share underpinnings with their iOS siblings. More than anything, I am glad developers increasingly have a theoretically viable way to target iOS and MacOS with largely similar code. But this is a big list of shortcomings to get through, and I hope we see some of these to-dos checked off during this year’s WWDC after 2021’s more tepid approach to Catalyst. Right now, it feels a little bit like the three main MacOS app frameworks are floating in unanchored space: AppKit is not the future, Catalyst is not ready to replace it, and using SwiftUI remains a long way off for big, complicated apps.