Possibilities for Mac/iOS convergence
By: Brian Webster |
A new story was published on Bloomberg this morning outlining rumored Apple plans to further unify the Mac and iOS platforms to make it easier for developers to offer apps for both. In their words:
Starting as early as next year, software developers will be able to design a single application that works with a touchscreen or mouse and trackpad depending on whether it’s running on the iPhone and iPad operating system or on Mac hardware, according to people familiar with the matter.
This leaves open a lot of questions about how exactly this would work, though, that aren’t covered by the story. Coming from the Mac side of things, I’ve been skeptical for years about continued speculation that Apple would eventually unify the two operating systems. I still don’t think a complete merger will ever happen, but there are a number of places on the spectrum between the current state of things and a full merge that could be viable. There are few levels of integration that I could think of here.
1. The simplest thing that Apple could do would be to allow users to purchase an app once and receive both the Mac and iOS version, rather than having to make separate purchases for each. This would basically mean a developer could link one of their Mac apps to the corresponding iOS app, and they would share receipts/credentials on the App Store (this could even include in-app purchases). The Bloomberg story points at something greater than this, but I think this step would make some sense even if the development side of things didn’t get unified right away.
2. On the opposite end of the spectrum, you basically have the “port UIKit to the Mac” crowd, which would basically let you take your existing iOS app and run it on the Mac with few or no changes. I don’t think this will be what happens, mostly due to the terrible user experience that would result. Have you ever tried actually using an iOS app in the Xcode simulator for any extended period of time? Yeah, it’s not good. So I think (hope!) Apple will do something more sophisticated than this.
3. An in between approach would involve taking some, but not all, elements of UIKit and related iOS frameworks and making them available on the Mac. The two platforms are different enough that taking the really high level stuff from UIKit (e.g. UIApplication) would not make any sense at all. After all, there are many things in iOS app development that just don’t apply on the Mac (e.g. handling rotation, backgrounding tasks… shake to undo?) and vice versa. Most of the pain points are usually in the UIView and UIViewController layers, since these basically have to be rewritten for their AppKit equivalents (e.g. NSView instead of UIView).
I could imagine a system that might work somewhat like the Carbon/Cocoa integration that Apple provided in the early OS X days, where you could do things like embed a Carbon view in a Cocoa view, mix Carbon and Cocoa windows in the same app, and so forth. There would still be some work to do for iOS devs to make their apps work well on the Mac, but I think this might be a good middle ground similar to Carbon, where 80% of the work is already done for you, and you’d just need to handle the extra hooks in order to have your iOS components behave inside a Mac environment.
One easy example of where this would be applicable is in extensions. To Apple’s credit, when they introduced extensions in iOS 8, they also brought the same technology to the Mac, with many (but not all) of the same extension points. However, anywhere you have to put up a user interface, such as when implementing a share extension, you still need to write both a UIKit and an AppKit version of that at the very least. For example, none of the sticker and special effect extensions that are on the iOS version of Messages are present on the Mac, and having some basic UIKit stuff available on the Mac might make this sort of thing more tenable to support cross platform.
As for x86 vs. ARM, while it’s possible that Apple could rig something so the UIKit bits would run on some sort of ARM coprocessor on the Mac (at this point I highly doubt it’s worth the time and effort for Apple to port all of macOS to ARM), I don’t think having to compile a separate Intel binary for the Mac version of an app would be too burdensome for developers. So, I would predict whatever happens it will probably still be Intel based.
4. And just for giggles, the pipe dream version of this would be an entirely new UI framework that supplants both UIKit and AppKit, acting as the new Cocoa to their Carbon. Of course it would be written from the ground up in Swift, and would produce rainbows and unicorns in addition to cross platform UI components. Given that Swift isn’t even ABI stable yet, I give this a snowball’s chance in hell of happening anytime soon, but it could be something to keep in mind down the road another 5-10 years.
In case it wasn’t obvious from my descriptions above, I think option #3 is probably the closest to what we might see if this comes to fruition. I think the advantages of this approach are that you’re not just taking an iOS app and plopping it in a window (which again, is terrible), and it provides something that can be approached incrementally. This means that you can do some fairly basic integration in the first iteration, and then gradually add more and more capabilities each subsequent year. I also think that anything that helps Apple themselves cut back on duplicated effort between the two platforms will help everyone, and hopefully mean that the Mac can keep better feature/bugfix parity with iOS and have more native apps available for it, while still keeping a full fledged mouse + keyboard interface. As a Mac developer, I’m cautiously optimistic about the possibilities here.