In Apple’s new Photos.app there’s a reference to UXKit. It seems to be a reimplementation of iOS’s UIKit for the Mac. This is a fun topic for me; when I was working on Twitter for Mac, I maintained our own UIKit re-implementation, TwUI.
TwUI was Loren’s creation, so he’d do a better job explaining, but basically it dealt with big pains at the time of Snow Leopard. It reimplemented APIs that were better on iOS, such as tableviews. Everything was backed by Core Animation, so it ran silky smooth.
After Snow Leopard, OS X APIs veered closer toward iOS. For instance, NSTableView adopted UITableview’s view-based layout.
Today, should you use TwUI for its Core Animation integration? I don’t think so. Any framework not blessed by Apple burdens you with ownership.
I spent a fair amount of time on Twitter for Mac not developing features, but working on framework stuff. For instance, I spent way too much time getting asian language input to communicate with OS X’s text input helper window, and had to settle on a pretty bad hack.
TwUI is great, but it’s become less relevant. If I built a green field Mac app today, and only supported recent versions of OS X, I’d stick to AppKit.1
An Apple sanctioned framework is an entirely different story. It would make developers’ lives easier, and save companies tons of time and energy through code reuse. All I want is 1) Core Animation backed everything, and 2) Software patterns identical to iOS.
I want this because it’ll make my life easier, but I don’t see it changing the overall ecosystem.
The iPhone/Mac Rubicon
Mac development is a small, friendly town. You see a lot of the same people, and everyone seems well behaved. The iOS App Store is a bustling metropolis. It’s loud and dirty, but it’s the only place you’ll see a U2 concert.
Big companies don’t bother with Mac apps. When they do, they seek the path of least resistance, throwing their website in a webview. Well intentioned people kept suggesting it at Twitter, and I had to keep shooting it down.
Even with a team of iOS devs and a solid iOS app as a starting point, there’s friction building and maintaining a Mac codebase. You need training in AppKit. Needless inconsistencies– such as the inverted Y axis– leads to duplicate code or per-platform conditionals. A new framework would cut this friction, and maybe that’s enough for a few companies on the fence, but if the world ran on APIs and code reuse, we’d all be using Windows phones.
Companies ignore the Mac because it’s fringe. Compared to iPhone, iPad, Android, and even Windows Phone, the Mac’s total users is a rounding error. If there are ten times as many iOS users in the world, that’s ten times the opportunity cost.
With iPad sales slowing, there’s similar risk of resource starvation. For all of Apple’s encouragement to develop a unique experience for iPad, size classes feel like a hedge. If developers won’t design a new experience for iPad, sneak in support when they supports larger phones.
I have API fan-fiction where Apple brings this all together: instead of pushing OS X to be more like iOS, add a desktop environment to iOS. Like Carbon’s bridge between OS 9 and OS X, create a compatibility API so all of your existing OS X apps run in this new platform. The big win is the
.ipa that runs on iPhone and iPad runs on the desktop.
It wouldn’t be “Write Once, Run Everywhere,” which always fails. Instead, pick and choose which APIs cross over. We already see this iOS: popover menu classes are available on iPad but not iPhone, purely for UX reasons. For the Mac, clamp down on any APIs that include the word “Touch.”
It’s all a fantasy, but pretty mundane in the scope of the decade. Once they reinvent the watch, and then television, what’s their next big bet? It feels right to come full circle and reboot an OS.