Marzipan

Saturday, 23 December 2017

Mark Gurman had an intriguing story at Bloomberg this week, but the problems start with the headline itself: “Apple Plans Combined iPhone, iPad and Mac Apps to Create One User Experience”.

Gurman probably didn’t write the headline, but it doesn’t even make sense. iOS has no concept of a mouse cursor and runs only on touchscreen devices. MacOS has no support for touchscreen devices and requires a mouse pointer. “One user experience” is neither possible nor desirable. The truth is that this effort by Apple is almost certainly not about cross-platform applications but instead cross-platform frameworks for developers. It’s developer news, not user news.

Gurman:

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.

Developers currently must design two different apps — one for iOS, the operating system of Apple’s mobile devices, and one for macOS, the system that runs Macs. That’s a lot more work. What’s more, Apple customers have long complained that some Mac apps get short shrift. […]

Apple is developing the strategy as part of the next major iOS and macOS updates, said the people, who requested anonymity to discuss an internal matter. Codenamed “Marzipan,” the secret project is planned as a multiyear effort that will start rolling out as early as next year and may be announced at the company’s annual developers conference in the summer.

Gus Mueller, designer and developer of the excellent Acorn, wrote an excellent piece reading between the lines of Gurman’s report:

I feel like this article from Gurman could have been reduced down to: “We think Apple might some day have a shared UI framework for iOS and MacOS. Apple could even create some sort of cross store bundling or a single store with a single binary for all platforms when using this framework (even though there’s nothing stopping Apple from doing this today). That sounds neat and wouldn’t it be cool if all platforms also used the same processor to boot? This may or may not happen starting next year, and it could very likely be canceled as well. Apple declined to comment on our sensational story.”

What about the crux of the article, that Apple is working on a shared UI framework between iOS and MacOS? I wouldn’t find it surprising. I could also see it being written completely in Swift (though personally I’d rather it be in Obj-C for maximum interop with existing frameworks).

But history is filled with cross platform UIs and write-once run-anywhere dreams. None of them turned out insanely great.

My only quibble with Mueller’s piece is that “None of them turned out insanely great” is way too generous a description of write-once/run-anywhere application frameworks. Most of them are terrible; none of them are good. Or at least none of them are good from the perspective of what makes truly native Mac and iOS apps good — which isn’t everyone’s perspective, but is certainly Apple’s.

There is a lot of work involved getting an iPhone app to work well on an iPad. That’s why you still see iPhone-only apps. Even with good new cross-platform Mac/iOS frameworks, there would be way more work involved to bring an iPhone app to Mac than there is to bring to iPad. There would be less work than there is today, but still far more than supporting iPad.

At a high level, the user interfaces for native Mac apps are written using a framework called AppKit. AppKit traces its roots all the way back to NeXTStep in the late 1980s. AppKit’s NeXTStep roots remain so pervasive today that the class names developers use while writing Cocoa apps for the Mac are still prefixed with “NS”.

When Apple created iOS, rather than port AppKit, they effectively hit the reset button and created a new-from-the-ground-up set of frameworks called UIKit. What AppKit is for the Mac, UIKit is for iOS (and now tvOS). UIKit was a fresh start — in short, a sort of “if we could do it all over again, what would we do differently?” take on AppKit. The result benefitted from decades of lessons learned and unwanted baggage dropped.

To name just one of many differences, where AppKit has NSColor, UIKIt has UIColor. NSColor and UIColor serve the same purpose, but they are not the same. Specifying an entire user interface can never be the same on platforms as fundamentally different as the Mac and iPhone. Specifying things like, say, colors, could be.

I’ve never seen anyone argue for AppKit to be brought to iOS. There have been many calls — ever since the first SDK for the iPhone appeared — for UIKit to be brought to the Mac. Guilherme Rambo wrote such a piece last year, “UXKit and Why ‘UIKit for macOS’ Is Important”:

The painfulness of working with AppKit is killing the Mac platform. There are some really awesome iOS apps out there which would benefit a lot from a macOS counterpart, but their developers simply can’t cope with the burden of developing for both, so they choose the one that’s most popular (hint: it is not macOS). Instead, people are making crappy web-based apps, shoving them on a .app with hundreds of megabytes and calling them “macOS apps”.

I didn’t believe it would be possible to have a single UI framework for iOS and macOS, but I changed my mind when I saw how UIKit works on tvOS. Think about it: it’s the same framework, but with a different visual language and functionality added/removed based on the needs of the platform:

• UIKit on tvOS has facilities to work with the remote control, controlling focus and the parallax effect that is ubiquitous on the platform.

• UIKit on iOS has touch input, gesture recognizers, toolbars and navigation bars

• UIKit on macOS would have window controllers, contextual menus and statusbar items

It’s more than a little hyperbolic to say that anything is “killing the Mac platform” today. The Mac is thriving. But there’s no question that maintaining parallel iOS and Mac apps is more work today than it could be. And it’s also true that for many companies, native Mac apps are prioritized lower than native iOS apps.¹

Gurman cites Twitter as an example:

For example, while the iPhone and iPad Twitter app is regularly updated with the social network’s latest features, the Mac version hasn’t been refreshed recently and is widely considered substandard. With a single app for all machines, Mac, iPad and iPhone users will get new features and updates at the same time.

That “will” in the last sentence is naive. If Twitter could somehow generate a “Mac app” from their iOS app without any effort at all, it would be a terrible Mac app. Nobody wants an iOS app running in a window on their Mac. At best, it would take less work than it does today to maintain the Mac app — but there’s no guarantee Twitter would do that work, regardless of how much easier it would be than today.

Gus Mueller:

There’s an easy solution for updating the Mac version of Twitter to have the same features as its iOS peers. Twitter has to care enough to update it. That’s it. It’s not as if there needs to be massive engineering efforts put behind it. It’s not as if the road hasn’t already been explored and the server APIs already exposed (which they must have done for the iOS version). They just need to put some effort and care to it. Tweetie for the Mac, which Twitter for the Mac is based on, was built from the ground up by a single person. All Twitter had to to was maintain it. And Twitter, Inc. couldn’t be bothered.

Caring is ultimately what makes true Mac apps Mac apps. Caring about the details, caring about the Mac way of doing things. No amount of shared frameworks between MacOS and iOS can make iOS developers care about doing things properly on the Mac.

Apple’s Mac Photos app is implemented largely using a private framework called UXKit, which is in many ways UIKit for Mac. Curious about UXKit, Rambo figured out how to create an app using it:

But the most interesting things are the UX-prefixed classes. Most of them are implementations of UIKit controls on top of AppKit. There’s UXLabel, UXCollectionView, UXNavigationController, UXViewController and much more. To see for myself whether I was right, I decided to try and build a really simple app using UXKit. The code is available on my Github. This app lets the user search for photos on Flickr and select them to see a bigger version, really simple.

While working on the app I noticed that it felt like I was working on an iOS app. […]

I think a developer who is familiar with UIKit would have no problem making macOS apps using UXKit. From what I know, the only apps that use UXKit currently are the macOS Photos app and the Pricing app (the one used at Apple Stores).

My concern with this whole situation is that even if this is all true — if Apple is indeed working on creating cross-platform UIKit-like frameworks for iOS and MacOS, and that the existence of such frameworks would spur more developers and companies to create Mac apps — it wouldn’t inevitably lead to the creation of good Mac apps.

Even Apple, much to my concern, has fallen short in this regard. Photos for Mac is one of the worst Mac apps I use. I love iCloud Photo Library syncing. Having the same set of thousands (tens of thousands, actually, in my case) of photos and videos in sync between all my devices, knowing that they’re all backed up on Apple’s servers, is a great experience. In terms of serving as a repository for your photos and videos, Photos for Mac works well.

But in terms of acting like a good Mac app, it does not. Even something as simple and fundamental to the Mac experience as drag-and-drop is all screwed up in Photos. When you drag an image out of Photos, you pretty much have to drop in the Finder first, then start a new drag with the new file copied to the Finder, before you can actually drop it into many contexts. Developer Ilja A. Iwas complained about this recently:

For almost a year now you cannot drag images from Photos to Safari, and in extension every other macOS application that uses WebViews, like our own GarageSale and many other 3rd party apps that work with images.

Imagine that: The default image handling app on the Mac platform cannot communicate via drag & drop with the default browser. And that’s been going on for almost a year now. On the desktop platform that used to excel in drag and drop!

Not a day goes by without frustrated users in asking our support team why GarageSale cannot receive drags from Photos.

Try dragging an image out of Photos while the main Photos window is in the background. It doesn’t work. You need to activate the window first, then drag. Any other file manager-type app on the Mac allows drags to be initiated from background windows.^{2 3}

Now try this: double-click and hold on an image in Photos, then drag. (That is to say, double-click on an image but don’t let go of the button on the second click.) In Photos for Mac, this initiates a drag. That’s nuts. Double-click, hold, and drag is how you create a selected range of multiple items in a list — the item you double-click on is the first item in the selection, and the ones you drag over are added to the selection. In a non-list view (like icon view in Finder), double-click-and-drag does nothing.

In addition to being non-standard, this particular behavior can get in the way when you just want to open an image, because Photos for Mac doesn’t allow for hysteresis for pointer movement during a double-click. Most Mac users will never notice this, but when you double-click on something on the Mac, the mouse pointer is allowed to move slightly between the first and second clicks. Such slight movements are especially common when using a trackpad, but they can happen with a mouse too. You don’t notice because the result is always what you intended. In early versions of Windows, which lacked hysteresis, double-clicking felt brittle, if not unreliable, because slight mouse movement between the first and second clicks would render the double-click attempt void. So it is with Photos for Mac — try to double-click on an image in Photos but inadvertently move the mouse pointer between clicks, and you wind up starting a drag instead of opening the image. If you’ve ever felt clumsy while trying to open images in Photos, it’s not your fault — it’s Apple’s.

And don’t get me started on some of the keyboard shortcuts in Photos. To get back from an image opened in detail view to the list of thumbnails, the Esc (Escape) key doesn’t work — you have to use the space bar. The shortcut for this might as well be Esc-swear-Space bar, because even after a few years now, I can’t get used to it.

It’s as though Photos for Mac was created by iOS developers who saw a Mac one time and said, “Sure, we can do that.”

Again, I use Photos — but only despite its crummy Mac interface. Photos is a poor poster child for the argument that Apple should make it easier for developers with experience only on iOS to create Mac apps.

Long-time Mac developer Michael Tsai (author of EagleFiler and SpamSieve) has similar concerns:

This has long seemed like an obvious thing for Apple to do, but I’m not sure it’s good for the Mac platform. The upside is that we’ll get lots of ports of iOS apps where previously there was no Mac app or only a poor quality Web-based one. The downside is that I don’t want to be using lowest common denominator iOS ports. I like using a Mac because of the apps that really take advantage of what the desktop has to offer. I’m continually annoyed by the apps that essentially put an iOS-style interface in a window and don’t support standard Mac conventions or features. I also worry that bifurcating the platform with UXKit and AppKit apps will inevitably mean that Apple will focus less on enhancing AppKit, while at the same time doubling the surface area for bugs. Having two classes of Mac apps would not be good, but AppKit going the way of Carbon would be even worse.

Jeff Johnson, on Twitter:

There seems to be a big cultural divide between iOS developers who came from the Mac and iOS developers who didn’t. Many in the latter group are OK with destroying the Mac, and that’s very frustrating to me.

And also from Johnson (this tweet is the start of a good thread):

Something that crystalized for me yesterday is how afraid many UIKit developers are of AppKit. Which is unfortunate, because the similarities vastly outnumber the differences.

In short, Apple’s goal should be to make it easier for developers to create good Mac apps, and easier for Mac and iOS app siblings to share code. Apple’s goal should not be to make it easier to get iOS apps to run on the Mac in slightly modified form. And I think it’s nonsensical to think that Apple is working toward a single unified OS. The best reason for hope on this front is the recent redoubling of Apple’s efforts on pro Mac hardware. The iMac Pro was not designed to run iPhone apps.⁴