While the Mac and iPad remain distinct products, Apple continues to bridge the gap between its desktop and mobile platforms. In 2014, for example, it introduced Continuity features like Handoff and Universal Clipboard that enable more seamless experiences across the Mac, iPad, and other Apple devices.
The next step in this process is Project Catalyst, which makes it much easier for developers to extend iPad apps to the Mac.
/article-new/2019/06/project-catalyst.jpg?lossy)
Starting with macOS Catalina and Xcode 11, developers can create a Mac version of an iPad app using UIKit, an Apple framework that until now was intended solely for iOS apps. Adding macOS support to an iPad app is as easy as opening an Xcode project and clicking the Mac checkbox under General > Deployment Info.
While the Mac version of the app should run after the box is checked, this is not always the case, as the Xcode project may contain code that no longer compiles due to frameworks, APIs, or embeddable content that is incompatible with the Mac, according to Apple's developer documentation:
Most iPad apps are great candidates for adaptation, but a few rely on iPad features that don’t exist on a Mac. For example, if your app's essential features require iPad capabilities like gyroscope, accelerometer, or rear camera, iOS frameworks like HealthKit or ARKit, or the app's main function is something like navigation, it might not be suited for the Mac.
Apple has instructions on how to remedy these compatibility issues.
iPad apps ported to macOS run natively on the Mac, utilizing the same frameworks, resources, and runtime environment as traditional Mac apps, according to Apple's developer documentation:
The Mac version of your iPad app supports many system features found in macOS without requiring any effort from you…
- 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.
Apple's updated Human Interface Guidelines are a helpful resource for designing and coding the ideal iPad app for Mac.
/article-new/2019/06/dc-universe-project-catalyst.jpg?lossy)
If this all sounds familiar, it is because Project Catalyst is Apple's public-facing name for this initiative, which has been referred to by its internal name of Marzipan until now. Apple's plans to allow iOS apps to easily run on Mac were first reported by Bloomberg's Mark Gurman over 18 months ago.
Apple provided us with a first glimpse of Project Catalyst when it brought the iPad versions of its Apple News, Home, Stocks, and Voice Memos apps to the Mac last year in macOS Mojave. Third-party developers are now able to follow suit in macOS Catalina, which will be released to the public in the fall.
Top Rated Comments
But I can write one app against UIKit and reuse even UI elements between all three platforms, because it is all UIKit.
Catalyst is UIKit for macOS. Nothing more, nothing less. But it looks like macOS is using the Pad idiom.
Yes. Catalyst (UIKit) was private in Mojave, and since Catalina is the first major version with UIKit as a public framework, it will require it.
It is like Universal Apps, but there's a key difference between Apple's approach and Microsoft's. Microsoft built UWP on top of WinRT (edit: the framework, not Windows RT, the SKU) that was part of Win8. These are "Modern" or "Metro" apps. The fact that you had to completely port an app to it to get the benefit made it expensive for established apps like Photoshop. And because of how WinRT worked, you may not even get all the benefit of it since there were some weird issues around WinRT in C++ that I don't know if they resolved in the Win 10 timeframe.
Apple played a longer game. iOS/tvOS/iPadOS and macOS already share a lot of frameworks: Foundation, AVFoundation, Core Data, Core Graphics, Core Animation, Map Kit, etc, etc etc. Before Catalyst, I could still write up an app with a single codebase that compiled for all 4 platforms, mostly. The problem is that AppKit and UIKit are different enough that you have to "fork" a piece of your code for AppKit and one for UIKit. This makes managing things a bit trickier and just more effort. By bringing UIKit to the Mac, what Apple is doing is saying to the (more numerous) iOS devs: "You can now bring your app to the Mac without having to deal with AppKit to do it".
The advantage here is that UIKit is something people already use. iOS has the larger developer base. It's now less of a "semi-port" and now a "tweak it for Mac like you do for tvOS or iPad" situation. That's important.
But, in many ways, because the two have shared most of their core frameworks for years, it was also a lot less work to get here. I think Apple was hoping that only having AppKit/UIKit diverged was enough to entice more devs, but I guess not quite.