Catalyst deep dive: The future of Mac software according to Apple and devs

SAN JOSE, Calif.—When Apple revealed macOS Catalina at WWDC this month, one related announcement drew considerable interest from Mac users and developers alike: a new way to turn iPad apps into fully native Mac apps.

Dubbed Project Catalyst, it promised to increase the number of quality native apps on the Mac platform by leveraging developers' existing work in the arguably more robust iOS (and now, iPadOS) app ecosystem. But it does raise questions: what does this mean for Mac users' future experiences? Will this change the type of software made for Macs? Is Apple's ecosystem a mobile-first one?

Then there are developer concerns: is Catalyst just a stepping stone to SwiftUI? What challenges can devs expect when adapting their iPad apps for the Mac?

Ars spoke with key members of the Apple team responsible for developing and promoting Project Catalyst at WWDC, as well as with a handful of app developers who have already made Mac apps this way. We asked them about how Catalyst works, what the future of Apple software looks like, and what users can expect.

The Mac is a popular platform among developers, creatives, and beyond. But while the iPhone and iPad App Store have thrived as one of the industry's most vibrant software ecosystems, the Mac App Store hasn't gained the same level of traction or significance, despite the presence of powerful applications that are not available on mobile.

Apple seeks to funnel some of its success with the iOS App Store over to macOS using Catalyst. We'll go over how developers use what Apple has built step-by-step, as well as what challenges they faced. And we'll share Apple's answers to our questions about how the company plans to maintain a high standard of quality for Mac apps as an influx of mobile-derived apps hits the platform, what Apple's long-term plans for cross-platform apps across the entire ecosystem look like, and more.

Before we get started, here's a list of the Apple representatives and third-party app developers we spoke with for this deep dive:

• Todd Benjamin, Apple's senior director of marketing for macOS
• Ali Ozer, Apple's Cocoa engineering manager who worked on the Catalyst project
• Shaan Pruden, Apple's senior director of partner management and developer relations
• Manu Ruiz, an engine software engineer at Gameloft who worked on bringing the iPad game Asphalt 9: Legends from iPad to Mac
• Alex Urbano, a graphics engineer at Gameloft who also worked on the Mac version of Asphalt 9: Legends
• Rich Shimano, an iOS developer at TripIt, a travel app that was brought natively to the Mac using Catalyst
• Nolan O'Brien, Twitter's senior staff software engineer who used Catalyst to bring Twitter back to the Mac

Let's dive in.

An introduction to Project Catalyst

Bloomberg reported way back in December 2017 that Apple was working on a project that would make developing apps for both macOS and iOS side-by-side easier. We learned at WWDC this year that one major component to that push is called Project Catalyst, which enables porting iPad apps to the Mac relatively quickly.

App developers can start doing this now with the beta version of Xcode, the development environment Apple maintains for making apps for its various platforms. To much fanfare on the WWDC stage, Apple claimed developers simply need to open their iPad app project in Xcode and click a single check box to be able to build a Mac app. Of course, it won't always be quite that simple—but it's closer than you might think.

The idea is to handle some of the difficult aspects of porting a mobile app to the desktop—like moving from a touch-based interface to a mouse-pointer-based one—automatically and quickly so developers can jump right into adding desktop-specific features where desired.

Here's what Apple's developer site says about it:

Mac app runs natively, utilizing the same frameworks, resources, and runtime environment as apps built just for Mac. Fundamental Mac desktop and windowing features are added, and touch controls are adapted to the keyboard and mouse. Custom UI elements that you created with your code come across as-is. You can then continue to implement features in Xcode with UIKit APIs to make sure your app looks great and works seamlessly.

Note that this is not emulation we're talking about; Apple instead sought to make it possible to build native applications for both the Mac and the iPad from the same Xcode project.

Apple dedicated multiple sessions at WWDC to educating developers on its efforts and what it considers to be the best practices for adapting iPad apps for the desktop. Todd Benjamin, senior director of marketing for macOS, explained to Ars why Apple has decided to make this a priority now:

We're at a stage at this point now where developers have fully developed iPad apps, and there's a great opportunity to take the work that they've done there, which not only leverages what they had done on iOS, but also takes advantage of screen space and some things that we can leverage nicely as we bring them over to the Mac.

Senior director of partner management and developer relations lead Shaan Pruden added:

[Developers'] customers had been asking them for a Mac version because they have a big install base on the iPad, and they just didn't feel like they had the wherewithal to spin up a whole other development team and do a port.

And why go from iPad to Mac instead of the other way around? "We have millions of apps out there for the iPad," Apple Cocoa engineering manager Ali Ozer, who worked directly on making Catalyst a reality, told Ars. "So there's a direction which makes more sense, at least when it comes to enabling developers."

Critically, bringing iPhone apps over to macOS is not what Catalyst does—they have to be iPad apps. This might seem surprising: the iPhone has one of the most robust software ecosystems in the world, whereas the iPad is mostly a subset of that. There are some iPad apps that aren't on the iPhone, yes, but there are countless iPhone apps that aren't on the iPad.

Benjamin said Apple made that decision because it's a more natural transition to bring an app from the iPad over to the desktop than it is to adapt an iPhone app over:

Just design-wise, the difference between an iPad app and an iPhone app is that the iPad app has gone through a design iteration to take advantage of more screen space. And as you bring that app over to the Mac... you have something that's designed around that space that you can work with and that you can start from.

Ozer noted that the move is also about pre-empting user concerns about mobile ports spilling into the desktop even though the ports aren't appropriate for the platform. "This is one way of making developers aware that an iPhone app in its current form might not be the right design," he said.

How it works

Many of the frameworks developers use to create apps for the iPad and the Mac are similar. Part of what Apple did here was bridge the differences that previously existed between the iPad and Mac versions of shared development frameworks. But the biggest gap is that between the UI frameworks.

Developers build user interfaces and functionality of iPad apps using the UIKit framework. Meanwhile, the Mac has a framework called AppKit that does many of the same things. Previously, Mac apps could not run apps made using UIKit, and iOS devices could not run apps made using AppKit. Even if a developer could reuse some pieces of their iPad apps when building Mac versions, doing so took a considerable amount of additional work.

When viewing their iPad project in Xcode, a developer can check a box to select the Mac as a supported device. After that's done, Xcode makes the following changes to the project, according to Apple's documentation:

1. Adds a bundle identifier for the Mac version of your app.
2. Adds the App Sandbox Entitlement to your project. Xcode includes this entitlement in the Mac version of your app, but not in the iOS version.
3. Adds My Mac to the list of destinations that you can choose when running your app from Xcode.
4. Excludes incompatible frameworks, app extensions, and other embedded content.

Barring any errors, the developer should then be able to deploy a basic version of their app for the Mac. The following Mac-specific features should automatically be part of the new Mac version, Apple says:

• A default menu bar for your app.
• Support for trackpad, mouse, and keyboard input.
• Support for window resizing and full-screen display.
• Mac-style scroll bars.
• Copy-and-paste support.
• Drag-and-drop support.
• Support for system Touch Bar controls.

From this point, the developer can add menu-bar items, apply translucency to the primary view controller, display and populate a preferences menu, add hover events, and so on.

Some frameworks are available on one platform but not another—for example, ARKit is not available on the Mac, so a developer porting an app that uses ARKit to deliver augmented reality experiences will want to consider that. In some cases, code pertaining to features and frameworks not present on the target device will automatically not be used.

In other instances, developers can, of course, use conditional logic in their code to deliver different experiences and functionality based on which device the software is running on. Apple, however, intended for that approach to be reserved for cases where functionality is simply not available on a certain device but is desired on another.

"We'd like them to use conditionals as little as possible because, you know, conditionals are different code paths that you have to worry about," explained Ozer. "And I think that the things we've tied to conditionals are APIs and features that are really very much Mac-only."

Apple says that many of the developers building the first third-party Catalyst apps managed to get an acceptable build running on the Mac within 24 hours. But each faced some challenges unique to each app.