In contrast to most WWDCs I can remember, the mood surrounding this year’s conference seemed more anxious, with developers’ excitement for learning the future of Apple’s platforms muted by a blockbuster Mark Gurman report late last year:
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.
What that meant nobody seemed to know. I think Gus Mueller reflected on it well:
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.
John Gruber corrected the latter sentence:
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.
Then, in a discussion on Rene Ritchie’s Vector podcast, Gruber said:
We don’t know if it’s good news or bad news. Bad news would be literally just like being able to run the equivalent of what you see in the iOS simulator. Just have a little rectangle shape of an iPhone or an iPad that runs in a window. Every click is like a simulated touch, and that’s it.
Anybody who’s ever tried running an app, like an iPhone app, in the Xcode simulator, it’s a great feature for debugging, but it’s horrible for using. It’s because it just doesn’t mesh with the mouse-and-keyboard paradigm of the Mac. It never feels right to do that.
In a gradient of garbage-to-great, that’s at the rotten end of the scale: a Mac app that’s a simulated iOS app — one that feels like it’s simply running on the wrong platform.
The best possible iteration of shared code between iOS and Mac apps is something that would be invisible to users. It would feel entirely native when running on either platform: an NSButton becomes a UIButton on iOS, for example; perhaps a UISplitViewController turns into a NSSplitView on MacOS. Save and open commands trigger the iOS equivalents instead of MacOS sheets. Stuff like that. It should be something that makes life easier for developers building cross-platform apps, and which users simply do not see any more than whether an app is built with Objective-C or Swift.
On the Mac side, especially, that means building software that adheres to well-established platform expectations. Becky Hansmeyer published a terrific and lengthy list, and I’ve excerpted a few items from it here:
Touch Bar support
Contextual menus
Tooltips
Multiple windows
File system access
Scroll bar elasticity
Drag and drop support
These — and many others — are the ingredients that make a true Mac app. But there’s something not on Hansmeyer’s list that I think is just as important, which is the feel of an app. That is: an app could, theoretically, support all of the ingredients on Hansmeyer’s list and still not feel like a Mac app — though I can’t think of an app off the top of my head like that. It is likely that you may find an app that somehow doesn’t feel right on MacOS and only then discover that it’s missing one or more of the features on this list.
The inverse can also be true and, I think, is more likely: an app may be missing a few of the things on Hansmeyer’s list, but it may still have that feeling of a good Mac app. Cultured Code’s Things, for example, doesn’t really allow user interaction with the file system, but it has long felt like the most polished todo app for the Mac. Aperture still feels like more of a Mac app than Lightroom ever will. All of Panic’s Mac apps feel like the best possible iteration of an app for the genres in which they reside.
A cross-platform framework must somehow preserve this Mac-specific quality for MacOS apps, even if the underlying code is shared with an iOS version. Each version of an app should be completely correct on each platform, even if they have shared code. To make an odd comparison, it’s sort of like tea. Now, I’m not a big tea drinker but, as best as I understand it, white, green, and black tea all come from the exact same plant. The differences in colour and flavour are based on when the tea is picked and how long it is aged, but it’s still the same leaf. Ideally, that’s what cross-platform apps are: individual, but with shared origins.
The first four apps that Apple has brought to end users based on their UIKit-for-Mac framework are nothing like this ideal. At their absolute best, they are passably lazy ports of their iOS equivalents; at their worst, as with Home, they sit comfortably near the ass-end of that garbage-to-great scale.
Actually, that’s a little unfair of me. Home, on my Mac, shows exactly the same inescapable error as it does on iOS. I cannot fully judge it. However, screenshots of the app in Andrew Cunningham’s review of Mojave clearly display an iOS app in a MacOS window frame, right down to the spinning “tumbler”-style picker controls. Its full screen view is completely hilarious.
The other three apps Apple has ported from iOS so far — Stocks, News, and Voice Memos — are slightly better, but not by much. They are, quite literally, scaled up and then scaled back down iOS apps, with a handful of MacOS-converted controls. The scaling is noticeable, particularly in text and fine-lined graphics like sharing icons; it looks cut-rate and sloppy. Touch Bar support is reportedly non-existent. These apps do not look or feel at all like real Mac apps. Recall that Notes and Reminders were brought to the Mac in Mountain Lion after being on iOS for years: both look like their iOS counterparts, but fit reasonably well in the MacOS environment — Notes far more than Reminders. Or look at Photos for a more robust and capable app that started life on iOS.1
But that’s not what was shipped in the public version of Mojave. I didn’t want to complain about the state of these apps prior to release because I didn’t think that was fair — plenty of bugs were fixed as the release date drew nearer. Unfortunately, they didn’t become any more Mac-like. That would be fine if these were one-offs, but Apple is planning on releasing this framework to developers just next year, and the initial results are not promising. They remind me of the janky apps you’ll find at the top of the free chart in the Games section of the Mac App Store. I worry that this will be increasingly common now that directly porting an app from iOS is something that is seemingly officially sanctioned, and I’m not the only one. These apps are not ready.
Or, here’s an even worse situation: maybe Apple does consider these apps ready. Surely they figured they were good enough to bundle preinstalled in the latest public update to MacOS. Are these the model apps for third-party developers to aspire to when they get to start porting their apps next year? I certainly hope not.
To be completely fair to the engineers who clearly worked hard on this framework, cross-platform porting probably does represent the future of a segment of Mac apps, unfortunately, and these particular examples are absolutely functional. But they’re still pretty much just tech demos — proofs of concept. Maybe these apps were shipped to an impossible deadline. I’ll tell you who I absolutely feel bad for, though: all of the hardware engineers who worked tirelessly to cram bright, high-resolution, and battery-friendly displays into Apple’s notebook lineup, only to see them draw a bunch of blurry text and horribly-scaled graphics.
Whatever the case, the fact is that these apps have now shipped, and they’re awful examples for the rest of the developer community to follow next year. Maybe — hopefully — this framework will become far more robust and closer to the ideal or, perhaps, start something new. I dread the possibility of a day a few years from now where we must navigate Mac apps this poor the way we do for Electron apps today and Java apps a decade ago. This piece is not about that future, though; it’s about today and the four apps brand new to the Mac. They are no good.