I’ve been thinking about what a unified Apple API could look like. One of the biggest issues is that iOS devices and Mac devices are very different, and even some iOS devices like the AppleTV aren’t even similar to devices like the iPhone or iPad.
One option Apple has is creating a new, massive API that exists on both iOS and Mac. This is a tremendous undertaking. It’s taken Microsoft many years of public iteration on their Universal Windows API, and adoption has not been quick. And Windows Universal apps are frequently targeted for not feeling like native desktop applications, which is something Microsoft has trying to improve on in the years since Windows 8.
A brand new API would also have to deal with the platform differences. Is there a good way to force an iOS application developer to think about menus on the Mac as they build their iOS app? Would a Mac app built on this framework simply have it’s menus go missing when it runs on iOS? It doesn’t seem like there is a good option here that doesn’t require losing a lot of what Mac users love, or complicating iOS.
I was thinking through the timing of this transition, and remembered that Apple will be ending support of 32 bit applications at the same time. One of the biggest problems with the 32 bit runtime on Mac is the fragile base class problem. I won’t get deep into the specifics, you can read more here. But, the fragile base class problem would prevent Apple from making serious changes to the core classes that made up AppKit, or prevent them from changing the class hierarchy.
But now that Apple could change the class hierarchy, what if we’re wrong about how we think about a shared framework? What if it’s not a layer on top of AppKit and UIKit, but a layer underneath?
Classes like NSImage and UIImage could be refactored to have a common ancestor, maybe just named Image. When you create an Image you get the platform specific version under the hood, but you can ignore that and work with Image’s shared cross platform functions. When you need something only currently available on the Mac, like image representations, you just downcast your image to an NSImage, and you have all your AppKit functionality back.
This would solve the hand wringing of losing advanced Mac features because you don’t actually lose anything. And as Mac features are pulled into the common layer as needed, iOS gains the advanced features as well.
It doesn’t let you write code once and have it run perfectly on both platforms. But I’m not sure that’s the point. I think Apple will want to avoid the mistake Microsoft did, and make developers still think about and specialize their apps on both platforms as necessary, much like they do with the iPad and iPhone. But not having to worry about things like NSImage or UIImage or NSView vs UIView could seriously turbocharge moving code between platforms.
This sort of setup would also prevent the sort of fallout we saw from the ongoing pure Swift vs Obj-C debate. AppKit and UIKit would continue to exist, just with a shared heritage. There wouldn’t be a need to fight about which API is best, all APIs would win.