Maybe 2018 will be the year UIKit replaces AppKit on the Mac

At the 2007 iPhone launch, Steve Jobs proudly proclaimed "iPhone runs OS X". In practice, iOS was relatively feature-limited and buttoned-down compared to macOS. It took Apple years to re-build the feature richness that macOS enjoyed in a modern and secure way for the mobile age.

Successive iOS releases improved the situation, and especially the last 4 years iOS made big leaps forward. Between iOS 8 and 11 we got app extensions, split-screen multitasking, APFS, drag-and-drop and a Files app. Together these brought iOS almost to the level of productivity of macOS. People are now using iPads as primary work machines, which was unthinkable in 2012.

This is great for the iOS ecosystem. As certain categories of pro users (writers for example) flock towards iOS, the market for pro apps grows. The app store thrives, and Pro apps like Ulysses, Scrivener, Pixelmator, Affinity have no trouble finding an audience of professionals paying good money. The ongoing debate around subscriptions reflects iOS's shift from content consumers towards content products. Some people may may not be happy with the trend, but overall it's a good sign.

What about macOS though? The perception grew that Apple saw the Mac as a "maintenance only" platform. Posts circulated on how Apple could revamp macOS. There was backlash on the hardware front over the lack of upgrades for the Mac Pro. This resulted in Apple's unprecedented move of pre-announcing both the "future modular Mac Pro" and the iMac Pro over a year ahead of their release date. Phil Schiller painstakingly swore that while Apple sees its own products as competing with each other for the right to exist, the Mac continues to be the spearhead into new territory to which other platforms will later catch up.

This explains why WWDC 2017 brought new frameworks targeted at VR content creation and high-definition video editing (2 categories of professionals which iOS will not service in the foreseeable future). But in general, there has been no major announcement on revamping macOS itself to match the reinvigorated hardware pipeline.

I think 2018 will be the year that changes.

Specifically I believe 2018 will be the year that a UIKit derivative replaces AppKit on the Mac, and I'd like to offer five six pieces of circumstancial evidence to support this speculation.

The first is reconsidering old evidence, namely the Photos UXKit discovery. This was discussed extensively in 2015. At the time there were two popular theories. People who know much more about frameworks than me believed UXKit was an early sneak peek at the future of macOS, while others thought it amounted to nothing more than an internal set of utility classes.  Whatever the internal arguments why Apple used UXKit on Photos, the fact they built it at all puts the usefulness of a more harmonised model beyond dispute. Any "AppKit isn't so bad" arguments are, in my opinion, rendered moot by the fact that Apple itself found that it needed to build a mapping layer at all. Looking back at this discussion 2 years later, the fact that they haven't released any of this to the public suggests to me that UXKit is more than a thin translation layer: utility classes are easily shared.

The second is a business argument around app store economics. As certain categories of professionals flock towards iOS, they start leaving the Mac behind. The fact that the Mac is no longer a growth market is problematic for developers. Apple is definitely aware of the fact that the Mac app store is struggling. Apple knows that at current development cost vs. revenue levels, releasing an app on the Mac is not a viable business model for many developers, even for those already releasing for iOS. One of the things Apple can do to alleviate that issue is reduce the cost of development by releasing a framework that reduces the burden on developers, and allows a larger common codebase between iOS and macOS. UXKit could be a (small) part of the solution.

The third is Apple's AppKit release notes. If you check the number of notes for AppKit in the past release, you see the last 2 years have seen less activity than before. Yes, I know it's a stretch to say that the number of release notes reflects how much effort is going into a certain framework, but as a rough proxy it does show that since 3 years Apple is paying less attention to AppKit than before. If they started developing a UIKit replacement around 2014 (when Photos UXKit was being developed), this is exactly how you'd expect to see it reflected in AppKit release notes.

The fourth is Swift. If Apple did indeed decide a few years back that UIKit would be replacing AppKit at some point in the future, while also deciding to replace Objective-C by Swift, the natural question for them would be in what sequence to do these successive brain transplants. One viable path would be to give Swift 3-4 years to stabilize before releasing UIKit on macOS. That would also make it more acceptable for them to make UIKit on macOS exclusive to Swift, leaving Objective-C behind on the Mac. There could be some resistance to that, but Apple has always been clear about skating where the puck is going. With Swift announced in 2014, and assuming Apple is working along some longterm roadmap or masterplan, 2018 would be a pretty good year to release a Mac version of UIKit.

Which brings us to the fifth argument - iTunes. People have been complaining about iTunes being bloated and beyond its expiration date for a few years now. Many expect Apple to break up iTunes into at least 4 apps (Music, Podcasts, TV / Videos, and some type of legacy device sync manager). Let's assume good faith for a second and assume that Apple both wants to replace iTunes by seperate apps, and ensure that this replacement can be viably maintained for 10-20 years to come. That would put Apple in the same position as most of its developers - having an app that was released on iOS first, wanting to bring it also to macOS while sharing as much of the codebase as useful, and needing to decide how to allocate limited resources in keeping all of these apps maintained.

It would make sense for Apple to solve this problem for itself in the same way that it plans to solve it for its developers: build the iTunes children not on Objective-C and AppKit, but on Swift and UIKit. Launching 4 (or more) new apps on the Mac is the biggest app launch Apple will have on the Mac in the foreseeable future, and comes right at the time when Apple would have to start thinking about re-writing some of its apps from Objective-C to Swift. By waiting a few years to upgrade iTunes, Apple may have given itself a more future-proof codebase, and given its developers some thoroughly dogfooded new frameworks. First on Photos, then on the iTunes children, then for the wide world.

So, IF Apple has a masterplan around moving the Mac from Objective-C & AppKit onto Swift and UIKit, and IF it has taken that technology masterplan into account in defining its iTunes roadmap... then signs pointing to the death of iTunes could also point towards the arrival of UIKit. Guess what started happening over the summer.

Update: With the release of High Sierra, I'd like to add a sixth piece of circumstancial evidence. There were a lot of reports that the windowserver was buggy and prone to crash. This could just be regular first release bugginess, but it would also be pretty much what you'd expect if Apple was not modernizing the graphics layer, but simultaneously already working on replacing the AppKit layer on top by a UIKit derivative for next year. They'd have to do basic retrofitting to keep the AppKit lights running, but you'd expect much of the engineering effort to already be in the Cocoa layer rather than the core graphics layer.

The timing couldn't be better.

Just my two cents.