Project Catalyst is designed to enable many of the existing one million iPad apps to also work natively on the Mac in a way that’s effectively indistinguishable from existing Mac software and transparent to users. At the same time, it’s also expected to help fuel the supply of iPad optimized apps. Here’s how.
At its Worldwide Developer Conference this week, Apple showed the results of its last year of work to bring UIKit iOS apps to the Mac via Project Catalyst
The Catalytic Converter
As the name suggests, Catalyst is a way to make something new happen with less effort or cost. Coincidentally or not, the name also plays against macOS Catalina, which will be required to use new Mac titles created using it.
Last summer, Apple initially introduced the concept of Catalyst—without any formal name—as an internal experiment to bring four titles created for iOS to macOS Mojave: News, Stocks, Home, and Voice Memos.
At the time, we described the new apps in the Public Beta release as “definitely still a work in progress,” but also clearly showing “the potential for iOS-only apps to transition to the Mac with less work for developers while offering a far better experience for users than simply being offered a web app interface.”
Mojave’s Home app was initially stuck firmly in iOS land, but it showed off the potential for UIKit apps on Macs
Others were far more critical, focusing on specific rough edges in the ported apps rather than seeing any potential for where the puck might go. Some concluded that it would be impossible for iPad apps to ever feel at home on the Mac. Excessive cynicism was also a common mistake 20 years ago when Apple first began showing off the original Mac OS X, which initially felt far less optimized and “snappy” compared to Mac OS Classic. It took time to reveal that Apple’s new software would eventually deliver a vastly better experience.
We’re already seeing vast progress in Catalyst. Apple has now taken everything it’s learned over the last year to take its formerly internal tools and open them up to third-party developers, so they can convert their own apps built for iOS into native UIKit apps capable of running on macOS Catalina.
Apple’s chief software architect Craig Federighi described the strategy as a “no brainer.” And Apple is confident enough in Catalyst to be using it to power key apps in Catalina, including the new Find My and Podcasts apps.
Step one: make a great iPad app
Catalyst isn’t intended to run iPhone-sized apps as floating desk accessories on the Mac desktop. Rather, it’s designed to build full-blown Mac titles that can take advantage of virtually all of the features of Apple’s desktop platform. For that reason, Apple refers to Catalyst as porting iPad apps to the Mac, specifically noting that the first step in the conversion is to “build a great iPad app.”
Ever since the iPad was first unveiled by Steve Jobs back in 2010, Apple has stridently maintained that the iPad was intended to be a distinct, new experience rather than just a “big iPod touch.” It’s consistently pointed to the large library of apps specifically optimized for iPad as a major differentiator from other tablets serving as stretched out phone apps, or PC “hybrids” that aimed at layering touch or tablet concepts on top of a conventional Windows PC desktop.
After a decade of iterations on their different approaches, it’s impossible to argue that Apple was wrong. Google’s many years of efforts to make it easy to run scalable Android phone apps across an infinite spectrum of various sizes of Android devices has resulted in a tablet experience so terrible for users that even the Verge admits there’s a problem.
And while there are fervent proponents of PC laptops with touch screens, or detachable hybrid PC-tablets that support conventional windowing and a mouse-style pointer, none of those products are actually selling in meaningful numbers, nor are they inducing any exceptional library of optimized software that makes very effective use of touch or a slate form factor.
Apple’s intentionally separate silos of iPhone, iPad, and Mac apps have not only resulted in an unparalleled, vast library of tablet-optimized apps but has also resulted in Apple selling by far the most tablets, without crushing its sales of conventional Macs. In fact, Apple continues to maintain a growing installed base of Mac users even as it has created an even larger base of iPad users. Rather than being a temporary fad like netbooks, Apple’s iPad has established a sustainable platform of users with specific needs served by a streamlined tablet experience. And for many, iPad is complementary to using a Mac while being a distinct experience.
Last year, Apple’s chief of software Craig Federighi made it clear that “NO,” Apple wasn’t seeking to undo this or “converge” its iOS and Mac platforms. Instead, the Catalyst experiment aimed to leverage the fact that there were many iOS apps that would be great to have on the Mac, if only there were a way to port them over and convert them into distinctly different, desktop-optimized experience that would feel familiar to Mac users and not like a hosted, awkwardly foreign compatibility shim.
Why a Catalyst was needed
While iOS and macOS have always shared much of their core OS software and offer very similar approaches in how their apps are built, there are significant differences in the details of the API frameworks that developers use to write AppKit apps for Mac or UIKit apps for iPhone and iPad. In some cases, that’s due to hardware differences or related to the very distinct nature of the Mac’s pixel-precise mouse pointer compared to the much larger touch shadow of an iOS finger gesture. In other areas, Apple simply wrote elements of iOS APIs differently because it had the opportunity to start fresh and break from legacy compatibility constraints.
As a result, to be proficient in both Mac and iOS coding, a developer would have to understand all of these different implementations and approaches. Beyond that, the code written for each would need to be maintained separately, so every change, feature addition, and bug fix would not only need to be made twice, but also in slightly different ways. There are obviously companies that do maintain both Mac and iOS versions of their software, but in many cases, these are handled by entirely different groups.
By doing a tremendous amount of work to handle many of these differences itself with Catalyst, Apple is now enabling iOS developers to only make a limited set of implementation-specific changes to deliver their existing UIKit code to run on macOS Catalina. The source code for both can now be maintained in the same Xcode project, enabling most changes to only be made once, dramatically simplifying the work required to maintain and optimize evolving code.
Building a better mouse trope
Moving an iPad app to the Mac using Catalyst involves checking a platform target box in Xcode that compiles the code for the Mac. The work behind the scenes is largely handled by Apple, both leveraging its compiler work to generate code portable across its hardware architectures, and the new frameworks in macOS Catalina written to support UIKit as a native Mac framework.
Apple states that when developers add “Mac” as a target in their iPad Xcode projects, “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.”
The company has also detailed that Catalyst automatically adds Mac support for System Preferences, Touch Bar input, contextual menus for editing text, and file management. And OS-specific changes are also made for features such as Activity view, Split View, File browser, and Form sheet. Developers do have to understand how to lay out interfaces that make sense on the Mac. Apple notes that “iOS conventions such as swipe to delete, action sheet commands, and controls at the bottom of the screen are optimized for touch interactions on a handheld device,” in contrast to “macOS conventions such as dedicated keys and keyboard shortcuts, menu commands, and controls at the top of the window are optimized for keyboard, mouse, and trackpad interactions and a separate display.”
Catalyst is designed to deliver apps with platform-specific features
Apple’s Human Interface Guidelines detail a variety of ways where Mac conventions are fundamentally different from iOS, including the app layout and navigation conventions, which can be specific to the type and purpose of the app being delivered. So there is more work involved for developers than just clicking a button, but it’s far less than starting from scratch on the Mac, or working to transfer a mobile app into a generic web service accessed through a browser.
Some of the work that developers will do to tailor their iPad apps for the Mac will also help them to deliver better iPad apps that take full advantage of the more sophisticated environment offered by iPadOS. That includes support for a larger working area enabling multiple concurrent apps using Split View, Slide Over, and Picture in Picture, with drag-and-drop interactions between them. Apple also recommends that developers add support for keyboard shortcuts, which are expected by Mac users and also an enhancement for any iPad users who opt to use a keyboard.
ARM and a lag?
Catalyst isn’t positioned as the singular future of building all Mac apps, however. Today’s AppKit developers don’t have to worry about being obsolesced anytime soon. In fact, Apple is continuing to enhance AppKit with various features, including the new SwiftUI. Instead, Catalyst simply aims to enable the broader world of iOS UIKit developers to bring their work to the Mac without learning much of the unique APIs that have historically been used to build Mac software.
That’s critical for small teams working on an iOS project that can’t quite justify writing a Mac version of their app from scratch. It’s also important for internal corporate developers who build a series of custom apps for iPads, and would like an efficient way to make those products available to Mac users as well. In general, Apple’s Catalyst strategy promises to make developers more productive in a way that will result in a larger spectrum of more consistent software titles across Apple’s platforms.
Catalyst isn’t “emulation,” which would involve running ARM code on a Mac CPU pretending to be an iPad chip. It’s also not a required step for Apple to eventually deliver ARM-based Macs in the future. In fact, it’s sort of the opposite, as it enables UIKit code to be compiled to run natively on the Mac’s Intel processors.
It’s also not pursuing the universal “write once, run anywhere” concept of Java VMs or Android, which host translated bytecode on a Virtual Machine across different hardware. Catalyst Mac apps are native code; it’s simply developed with a different set of tools more familiar to coders experienced with working on iOS projects.
A fundamental misunderstanding
Writing for Digital Trends, Tyler Lacoma wrote “the goal of Catalyst is to make apps on both operating systems universal, which means that Mac apps will also be able to cross over to iOS.” He also suggested that it may be part of plans to “officially merge the iPadOS and MacOS at some point,” but neither of those ideas are accurate.
Owen Williams put together a far more bizarre take on Medium that imagined Catalyst was Apple’s effort to destroy Electron, a cross-platform tool for building web apps that try to look native on various platforms. He cynically described Apple’s Catalyst as a “hail Mary move designed to bring developers back to the company’s platform,” using paragraphs of dramatic language that desperately tried to portray the most successful tech company on the planet as a has-been dinosaur coughing up its last gasps at relevance while the really important players in the world, like Spotify and Slack, move to web apps.
He scoffed at the partners Apple demonstrated on stage at WWDC using Catalyst to deliver their iPad apps on the Mac as being “a racing game nobody’s heard of, and a handful of other forgettable products,” while wondering aloud why “big names like Netflix or Amazon Prime Video” were not there, without even mentioning Twitter.
Williams also cited what he called “a better example of this idea” in Google’s efforts to bring Android apps to Chromebooks. The entire article dripped with contempt and derision, but it failed to comprehend what the point of Catalyst even was.
Catalyst isn’t a ploy to get web services to build native Mac apps. It’s simply a way to leverage the fact that there are tons of native iPad apps, driven by the reality that there are around 400 million iPads in use. There are “only” 100 million Macs in the active installed base, and similarly proportional fewer developers who are fluent in building AppKit Mac software.
iPad development is bolstered by the fact that there are even vastly more iPhones in use. The potential for leveraging the existing base of developers with experience in UIKit coding to rapidly produce new Mac titles will be substantial. Last summer, Upwork cited UIKIt as one of the top twenty fastest growing skills among freelancers.
Catalyst will bring iPad games to the Mac with native Metal graphics
Games are one area in particular where existing iPad titles can be expected to make a splash on the Mac. Apple highlighted the work of Gameloft to bring its popular Asphalt 9 racing game to the Mac using Catalyst, stating that the team was able to make the initial transition in a day. Because modern iPad games make calls to Metal to draw their graphics, Catalyst can leverage Metal on the Mac to render scaled up graphics using their more powerful GPUs.
Williams scoffed at a game he wasn’t aware of, but gaming on iOS is huge because iOS itself is huge. Making it very easy to port the vast library of iPad games to the Mac will be blockbuster.
