The Reaper
Brent Simmons responds to Steve Troughton-Smith’s “(Don’t Fear) The Reaper” with “Still Fearing the Reaper”:
So, knowing how this has worked out in the past, why do I fear the reaper?
Because bringing UIKit brings no new power. If anything, it subtracts power. UIKit apps — at least so far — are all sandboxed and available only via the App Store. They don’t offer everything AppKit offers.
In the piece Brent is responding to, Steve compares bringing UIKit to the Mac (via Marzipan) to the transition from Classic Mac OS to OS X (via NeXTSTEP); a transition that proved to be enormously successful. But I don’t buy this comparison. Cocoa, with its emphasis on model-view-controller, object-oriented programming, and framework-driven development, was a fundamentally different approach to software development than the Macintosh Toolbox—one with advantages that are easily summarized, for example the Cocoa Wikipedia page states:
In providing framework support for all three MVC domains, Apple’s goal is to reduce the amount of boilerplate or “glue” code that developers have to write, freeing up resources to spend time on application-specific features.
Developers got more functionality for free when they used Cocoa (while also losing some control). Here’s how Gwynne Raskind, writing for Mike Ash’s NSBlog, describes working with the menu bar with the Macintosh Toolbox:
Menu commands are passed around in their raw form as 32-bit integers encoding the menu’s resource ID in the high 16 bits and the item number in the low 16 bits. To figure out what to do, one extracts these two words and branches based on them. Yes, this means your code is intimately and directly tied to the exact layout of items in your menu resources. You remembered to make a constant for every menu ID and item number, right? No? Wow, are you in for a fun time.
The advantages of Cocoa are easy to explain. Unlike the advantages of UIKit relative to AppKit. The main argument1 I’ve heard is that UIKit is built around Core Animation, whereas similar functionality had to be retroactively added to AppKit. But animation is more important in UIKit. Gesture-driven interfaces couple well touch with direct manipulation; many interactions that work great animated on iOS (like swiping right to go back) don’t work as well on macOS, and are more naturally replaced with mouse clicks and keyboard shortcuts that result in instant transitions.
The real motivation for UIKit on the Mac is that more developers know it, and therefore more code is being written for it. This is the same argument for Electron and React Native: “We know how great apps are made, but we’re going to use this other thing instead because our developers already know it” (“We’ll make up the difference in volume!”). Has that approach ever resulted in great apps? You make great apps by making that your priority, not developer familiarity.
-
The other arguments I’ve heard are that the coordinate system is inverted between iOS and AppKit, and that the two frameworks have a bunch of classes that are similar between the two. ↩︎