Skip to main content

The future of the Mac comes from iOS apps

The future of the Mac comes from iOS apps

/

Bringing iOS apps to the Mac, on macOS’s terms

Share this story

Apple made a big splash at WWDC this year when it announced that it would be letting developers port their iOS applications over to the Mac sometime next year — and that Apple had already started the process by bringing over the iOS versions of the Home, Stocks, News, and Voice Memo apps to macOS 10.14 Mojave.

The project — rumored to be codenamed Marzipan — is still in the early stages, and Apple isn’t even planning on offering it to developers until 2019. And there’s already a fair amount of confusion and outcry over what Apple’s doing here: whether or not it will see the death of the traditional Mac app as we know it, exactly how these new kinds of apps will work, whether they’ll feel like traditional “native” Mac apps, and even whether or not it’s fair to call these apps “ports.” So here’s what’s actually going on.

To understand what Apple’s doing, first we need to understand why we’re even having this discussion in the first place. Apple wants to make it easier for mobile developers to get something like their mobile apps on the Mac.

Why? Well, for one thing, it’s clear that there are way more developers making iOS apps than Mac apps right now. The Mac app ecosystem isn’t necessarily in trouble, but compared to what has been happening on the iPhone for the past few years, it definitely feels a little stale. Making it easier to move iOS apps over to the Mac would certainly help.

As Apple developer Guilherme Rambo wrote in a piece a few years back, right now, some developers are often forced to choose between developing and supporting an iOS app or a Mac app — and in a world where there are far more iOS users, the Mac often misses out on great software.

And getting small, mobile-first apps on the desktop turns out to be wildly convenient. Having used Android on a Chromebook, it’s really great to have a lightweight app for lightweight tasks like scrolling Instagram or firing off a to-do list. Windows has been trying to do something similar with its frameworks (to limited, but increasing success), and Android apps on ChromeOS are out of beta, although they still need to add things like windowing support.

The trick in all this is how you get those mobile apps ported (or whatever word you really want to use) over from mobile to the desktop. And Apple’s solution is, in many ways, the most interesting take on this problem we’ve seen yet.

Let’s start with the difference between Mac and iOS apps. After all, at first glance, they seem to be pretty similar: they use the same base code languages, like Objective-C or Apple’s own Swift, and plenty of the underlying APIs are the same.

So what’s the difference? It seems blindingly obvious to boil it down to this, but it’s the user interface. Mac apps work with a keyboard and a mouse, while iOS apps work with a touchscreen. Simply moving iPhone apps over to the Mac in a way that’s similar to Google’s first betas of Android on ChromeOS is not the experience Apple wants. At all.

So Apple’s solution is to give developers the tools they need to make iOS apps get a more Mac-like user interface.

Until now, many Mac applications were based off a software framework called AppKit, which provides all the user interface elements that make a Mac app what it is: all the windows, menus, buttons, scrollers, and text fields, along with all the high-level software-side things your computer needs to actually display applications. AppKit dates back to the 1980s, descended from the original NeXTSTEP Application Kit. (For a more detailed history, here’s a good place to start.)

Pre-Marzipan: macOS apps are AppKit-based, and iOS apps are UIKit
Pre-Marzipan: macOS apps are AppKit-based, and iOS apps are UIKit

When Apple developed iOS, it created an entirely new software framework for displaying applications, called UIKit, which was designed for the smaller screens and more limited touch controls that iOS devices offer. But that means that a huge chunk of how iOS apps are displayed on devices (down to the way colors are shown, as pointed out by John Gruber here) uses different fundamental code frameworks from Mac apps. Adding to that complexity is that AppKit is designed for mouse and keyboard inputs, whereas UIKit is designed for touch.

With Marzipan, Apple is looking to bring over the UIKit framework to Macs, meaning that developers will — in theory — be able to bring over a version of their applications that will run on Macs, without having to completely rewrite them from scratch for the AppKit user interface. (Additionally, by adding UIKit to macOS as a native framework, the ported apps will run natively, instead of in a simulator or emulator). Note that Apple is adding UIKit, not replacing the traditional AppKit. Both will live side by side. Here, look at a chart!

There’s already precedence for this sort of porting in Apple’s own ecosystem — iPad apps and tvOS apps for the Apple TV already work on a similar basis. They’re built in UIKit and share the same code as an iPhone version. But developers can more easily port them from one platform to another, and each platform still has its own interface with its own considerations, design, and controls. Just like you don’t expect an iPad application to simply be a giant iPhone app, or an Apple TV app to work like an iPad app with a remote control, Marzipan applications ported to the Mac — again, in theory — would have their own user interfaces and designs and layouts best suited for the desktop.

That’s the theory, anyway. But in practice, having tried out a few of Apple’s new apps on macOS Mojave, these apps feel a lot like iPad apps. You can’t tap them, of course, but there’s something about the layout and the controls that feels very much like the iPad. You can resize the windows (unlike Android apps on ChromeOS), but the redrawing of the window contents is sometimes a little slow. There’s just not a classic Mac feel to these apps.

There’s no app where that’s more apparent than the Home app, for controlling all the smart home devices you have. It looks a lot like a straight port — with big giant buttons for everything that looks like you should tap it. But you can’t tap it because Apple fundamentally believes touchscreens on laptops are a Bad Idea. As we do almost every year now, we asked Apple why that’s the case, and the answer hasn’t really changed: Apple believes touchscreens on laptops are uncomfortable to use and most user research shows that even customers with touchscreens barely use them.

But don’t come away from this thinking that the end result is going to be a bunch of apps that look and feel just like iPad apps on the Mac. These few apps Apple has released are just the first cut, and Marzipan is at least a year away from being available to developers — Apple says it’s a “long-term project.” Over the course of the next year, we expect that Apple will develop the frameworks and APIs to make these apps feel a little more native to the Mac. And as pointed out by Steve Troughton-Smith, poking around the rudimentary Marzipan support in the Mojave developer beta suggests Apple is already starting do just that: adding interface elements, like the classic Mac app sidebar to UIKit, that let developers make iOS apps feel more at home on macOS.

Plus, we’ve already seen a bunch of untapped (so to speak) potential in these apps. When I started diving into the Mac menubar for these apps, all the classic Mac File and Edit and View menu options were there. There were a few keyboard shortcuts, just not as many as you’d expect. But it would be quite simple to add more.

Marzipan is still in the early stages

Right now, Marzipan is still in the early stages, and only Apple has access to it (unless you’re very good at digging through Apple’s filesystems). The four apps that Apple has ported still sure do look a lot like iOS apps that just run on a Mac, which might not be the best start as examples for developers looking to follow suit if the goal is to have good, native Mac experiences.

As Tapbots developer Paul Haddid commented on Twitter, “UIKit on Mac feels more like running an iOS App in a resizable simulator than a next gen Mac app,” and Troughton-Smith’s early experiments seem to agree, noting that the resizing of UIKit windows is currently pretty sluggish.

As noted by Apple’s senior vice president of software engineering Craig Federighi in an interview with Wired, Apple is already planning to help developers on their way in this process. Once the tools roll out to developers next year, they’ll be able to designate in Xcode that they want to make a variant of their app that will run on macOS, which will automatically replace how some parts of the app interact. (For example: long presses on iOS will morph into a two-finger right click on a Mac).

In theory, could developers just simply do the bare amount of effort and just make a windowed version of an iPhone app with Marzipan? Sure, and there will likely be some low-effort attempts at doing just that. But that’s missing the point of what this is supposed to offer. The goal here isn’t to replace native Mac applications with iOS versions — the idea is that developers will be able to make bespoke, Mac versions of applications that otherwise wouldn’t have ever made it over to macOS, and expand what developers can offer on the Mac without having the extra lift of writing a new, separate app from scratch.

It’s the same reason why ported iOS apps won’t necessarily indicate that Apple is making a touchscreen iMac or MacBook Pro, in the same way that tvOS running ported UIKit iOS apps doesn’t mean that Apple’s making an iPad without a touchscreen that only works through a TV remote. Ideally, these will in some form still be Mac apps with the same mouse and keyboard focus that any Mac app entails. (Then again, it doesn’t mean that Apple isn’t doing that, either. Predicting what Apple will or won’t do on any given day is tough.)

There’s still room for traditional Mac apps for developers who choose to support them

That said, the ported apps won’t be a 1:1 recreation of an AppKit app, either: UIKit apps are still UIKit apps, which means — at least right now, based on how Apple’s own apps look — there’s always going to be some hereditary DNA, like this extremely iOS interface from Apple’s ported Home app. But that doesn’t meant that Apple won’t be tweaking this over the next year, or that we won’t achieve some sort of middle ground. And there still will presumably always be room for traditional Mac apps for developers who choose to support them.

But there’s another part where UIKit apps might serve on macOS — replacing the web-app-style Electron applications that have sprung up in recent years like Slack and Simplenote with native UIKit-based ports of the iOS counterparts. A lot of the most popular apps on the Mac right now are Electron apps, and that could potentially be a threat to the Mac. If everybody gets used to just using modified web apps, what’s to stop them from switching to a Chromebook or (heaven forbid) Windows? Not that much!

And developer David Barnard argues that UIKit-based apps for desktop could offer those convenient, app-based experiences from our phones on computers more easily, especially for services that have better apps than websites (like banks or weather apps).  More to the point, Marzipan apps could probably offer a better experience than Electron apps. Look no further than Slack, which is a RAM-hogging goliath on the Mac but runs sweetly and smoothly on the iPad.

A lot of this will depend on what Apple makes available to developers — right now, there’s no word on when these tools will start rolling out to third parties to start tinkering with beyond “next year,” much less a consumer release. And there’s still plenty of questions, like whether UIKit ported apps will be offered as universal software like how iOS, iPad, watchOS, and tvOS apps are currently bundled, or whether or not developers will be able to offer both UIKit and AppKit versions of their apps on the Mac App Store.

There’s still plenty of questions

But if developers are able to take advantage of the potential that Apple seems to be offering here — and again, that’s a big, theoretical “IF” — it could mean a fresh wave of new, native apps for the Mac that will hugely change how we interact with our computers, much in the same way that apps have forever changed the mobile landscape.  

Oh, and two final pieces of completely unjustified speculation, just for fun.

First: One of the knocks on the iPad Pro is that there aren’t enough “Pro” apps on the level of what’s available on the Mac. But the iPad Pro has such a powerful processor and there are so many capabilities built-in to the iOS operating system now, that issue seems to be more of a failure of imagination than a failure of the operating system to support them. Maybe if developers get in the habit of making powerful apps for the Mac with these new tools, they might just go ahead and make them available on the iPad, too.

Second: iOS apps run on ARM processors, Macs run on Intel processors. So far as we can tell, there’s no real hassle in getting Marzipan apps going on those Intel chips. If you were thinking of maybe someday making an ARM-based Mac, you might want a bunch of apps that you know would run well on them!