1. 55
  1. 4

    On macOS the situation is not quite as chaotic and fragmented, but there is an analogous evolution from Cocoa (AppKit) to SwiftUI; going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter but not the former. There was a similar deprecation of Carbon in favor of Cocoa, many years ago.

    This comparison is a bit off: Cocoa and Carbon were independent of one another. Carbon could be deprecated and removed without affecting Cocoa. (It’s before my time, but wasn’t it explicitly a compatibility layer for Mac OS 9 devs to keep their code working for a limited time?) SwiftUI is built on top of Cocoa’s AppKit on macOS, and on UIKit on iOS and tvOS. AppKit and UIKit are a long way off from deprecation because they are dependencies of SwiftUI. SwiftUI views and AppKit or UIKit views can embed one another as well. So it’s really one system with two levels of abstraction you can choose.

    Besides that, I appreciated the discussion of targeting the compositor. That Mac OS X 10.5 feature that exposed the compositor richly is Core Animation, which underpins every UIKit view. We do sometimes drop down and use it for cases where many individual views wouldn’t be performant. But it’s all drawing—it doesn’t have any handling of input events. So it really can create a lot of work to build to the compositor instead of the system view layer.