How iOS Apps on the Mac Could Work
Nobody builds apps for the Mac. Slack has a solid iOS app that scales up to the iPad just fine. Attach the smart keyboard, and you’ll find keyboard shortcuts. It scrolls better than their site, and I never see a loading screen. It’s a perfect candidate to run on the desktop, yet they wrap their site in an app-launcher and call it a day.
Basecamp? A web view. Wordpress? Web view. Even the Mac App Store itself is a webview.
I hate imposter apps, but I get why companies settle. Big companies hate adding platforms. Designers need to build more designs, QA needs to test more environments, and business people struggle to translate “native app views” into the accepted industry metric, “page views.” It’s no wonder companies resisted native mobile development for years in lieu of cross-platform HTML5 apps.
If you needed a stronger case to ignore the Mac: it isn’t just a “Compile for OS X” checkbox. You need to hire developers with OS X specialization, and maintain a parallel codebase.
This isn’t just Big Company Bean-Counting.™ Take Sketch, absent from iOS citing risk:
We cannot port Sketch to the iPad if we have no reasonable expectation of earning back on our investment. Maintaining an application on two different platforms and provide one of them for a 10th of it’s value won’t work, and iPad volumes are low enough to disqualify the “make it up in volume” argument.
They think trials are an essential way to reduce risk. I think another option is to make supporting iPad so effortless you have to ask, “Why not?”
Let’s be clear: a lazy port of an iOS App to OS X is a terrible user experience. You should rethink touch-screen interactions for a keyboard and mouse. But there are significant areas that don’t need reimagining. If you ask Pinterest to rewrite its iconic layout for a different UI framework, it’ll shrug its shoulders and wrap its site in a webview.
Where iOS and OS X Diverge
While OS X and iOS share a ton of lower-level APIs, they completely diverge around the UI. The former is powered by AppKit, which goes back to NeXT, and the latter is powered by UIKit, was which written from the ground up to support the iPhone.
It cuts all the way down to the coordinate system. On OS X, the origin sits on the lower left, while on iOS it’s the upper left:
But UIKit diverges on an even deeper level: it was designed around GPU accelerated rendering. Every UIView is backed by a Core Animation layer, which works hand-in-hand with the GPU for silky-smooth scrolling.
When Core Animation made it back to the Mac, layers were opt-in, presumably for backward compatibility. Even when you enable them, they feel grafted on NSView.
There are UIKit reimplementations like TwUI and Chameleon, the latter seeking an identical API. In theory, you could share 100% of your UI code between platforms. In practice, these frameworks fight an uphill battle, because they're third-party.
Even among Apple’s Mac developers, there’s demand for a UIKit architecture. Last year’s Photos.app included UXKit, and Game Center uses a UICollectionView replica.
What I Expect
Don’t expect today’s iOS apps to launch on macOS without any changes. Look at tvOS.
tvOS is derived from iOS but is a distinct OS, including some frameworks that are supported only on tvOS.
It runs UIKit, with just enough stripped out to force you to rewrite your interactions for a TV experience.
One Bundle to Rule Them All?
TV apps have such a different interaction model than a touch screen, you’ll probably end up with a radically different design.
When porting an existing project, you can include an additional target in your Xcode project to simplify sharing of resources, but you need to create new storyboards for tvOS. Likely, you will need to look at how users navigate through your app and adapt your app’s user interface to Apple TV.
Even if you could bundle a tvOS app with your iOS app, the disadvantages (e.g. coupled releases) outweigh the advantages of shared code. I’ve known iOS developers who regretted shipped a universal iPhone/iPad app, because of the tight coupling. Sometimes you’re just better off just putting that shared code into a framework.
That said, if you look at most of Apple’s ports between Mac and iOS, they’re very similar. If Apple envisions the Mac and iOS experience as mostly similar, it’s very likely you could bundle a Mac app with your iOS one.
As a developer, only dealing with a single app with a single bundle ID simplifies stuff like sharing data between devices. Again, this is about reducing friction for existing iOS devs to add a new platform.
What about download size? Since one runs on x86 and the other runs ARM, you’d need two architectures bundled into one binary, similar to fat binaries, from the Mac’s transition to Intel. Well in iOS 9, Apple introduced App Thinning, so you only download the code that runs on your native platform.
Interface Idioms
In iOS 8, Apple added “trait collection,” and attribute that lets you check details of your platform. The Interface Idiom property today includes iPhone, iPad, TV, or CarPlay.
You check the idiom to make high level decisions about the interface. For the longest time you couldn’t create popovers on the iPhone, so you had to check that you’re on an iPad before using UIPopoverViewController, or else it would fail. According to an Apple designer, popovers give a bad user experience on a tiny iPhone screen, so this discouraged bad decisions. Since iOS 8, you can opt-in if you really know what you’re doing.
In theory you could restrict Mac features, like floating palettes, to a Mac idiom.
Sandboxing
In 2011, Apple added sandboxing to OS X. If you’re porting an iOS app to OS X, it should just work.
Handing Larger Sizes
What about the coordinate system? If you’re using Auto Layout it shouldn’t matter. Instead of assigning hard coding coordinates, you specify rules for how the views should lay out, relative to each other. It’s like CSS, but not horrible.
In the following example from the docs, each blue line is a rule (constraint). So long the rules make sense, Auto Layout will just figure it out for you:
There’s not a (0, 0) in sight. You can resize that window to any size and it just works.
Unfortunately, many apps are still using hard-coded values. It’s likely Apple will flip the coordinate system, exclusively for apps running UIKit. If you link against AppKit, you get the existing coordinate system. It would just complicate things if you mix-and-match UIKit and AppKit in one app.
Avoiding Giant iPhone Apps
What about the “Stretch out the iPhone App” UX abomination? They already dealt with it on iPad with Size Classes, which encourage designing for screen real-estate space, not hardware. Each dimension can be either “compact” or “regular.” For example, an iPhone’s width is considered compact, and a full screen iPad app is regular. From the docs:
So if you’re Facebook, and you only want to show trending topics on the side of the screen when you have a lot of available real-estate, you can can that you’re in a “regular” width. Why not just check if it’s iPad? An iPad app can change from regular to compact if the user starts multitasking, and shrinks the app.
The Mac could operate the same way, changing size classes when you resize the window past certain thresholds.
Sooner Rather than Later
Every WWDC for the last five years, I’ve thought, “This could be the year.” The difference from then and now? My outlook has changed from “wishful thinking” to “inevitable.”
It’s in Apple’s best interest to get professional apps, like Sketch, on iOS. Contrast “Photoshop Expression” running on an iPad with the real Photoshop running on Microsoft Surface.
It looks like even Apple has abandoned OS X. They aren’t hiring any new AppKit developers, and the the Mac App Store has been broken for years. What if they’re finally abandoning the old platform to pour all resources into the unified one?
In the last five years, Apple has changed. iOS 7 showed they’re willing to break from tradition. Apple Watch showed they’re willing to take risks, because, “Why not?” They haven’t taken a risk on the Mac since 2010, with the “Back to the Mac” event.
They say Mac OS X will be rebranded “macOS” for WWDC 2016. This could be the year.
