Our experience with Mac Catalyst
This blog from Darren Mariadas and Justin Maciburko from our iOS team gives a summary of their implementation of Mac Catalyst, and how they took a client from having no Mac presence to being #3 on the Mac App Store (Health & Fitness).
During WWDC 2018, Apple’s annual ‘Worldwide Developers Conference’, Project Catalyst was announced to the wider apple developer community. Formerly known as Project Marzipan, Catalyst was Apple’s promise to port the arguably more popular iPadOS app ecosystem to MacOS, by allowing the development of a universal app that can act as both a native iPadOS application and also an indistinguishable MacOS application. This raised a lot of concerns around the challenges that can arise in doing so and a lot of developers simply weren’t convinced that it would be worthy from both a time and effort point of view. After all, can it really be all that simple to translate the user experience from a touch based interface to mouse/pointer based one? Here’s what Apple says on their documentation:
“Your newly created mac app runs natively, utilising the same frameworks, resources, and runtime environment as apps built just for Mac. Fundamentally, Mac desktop and windowing features are added, and touch controls are adapted to the keyboard and mouse. By default, your app will scale to match the iPads resolution. You can choose “Optimise interface for Mac” to use the Mac idiom, running your app using the native resolution of Mac. This gives you full control of every pixel on the screen and allows your app to adopt more controls specific to Mac, such as pull-down menus and checkboxes.”
We couldn’t wait to dip our feet into this new technology and see if it really is as simple to port an existing iPad application of ours, over to MacOS.
The perfect client
We have a client who felt like a natural fit for Catalyst, as a major goal of their app was to reach as many people as possible. The app in question uses the collective power of smartphones to fast track research by downloading tiny parts of huge research projects from the cloud, calculating them, and sending the results back to the specified research team. With more people powering projects, the faster they’ll be completed — and in turn, more research can be done.
The amount of time estimated to release a working Mac Catalyst app was crucial to whether we would be able to go ahead or not. To reduce the overhead of needing new image assets that scale well on a desktop, we made the decision to fix the window to an ideal size when built for the platform. However, doing this still left some issues that needed to be resolved before we felt comfortable releasing to users.
As parts of the UI (and in some instances, logic) would need to be varied only for Mac, we leveraged extensions to reduce the code noise this would bring while retaining clarity. For example, this extension on Bool used to wrap a Mac Catalyst preprocessor check:
This allowed us to quickly and easily add catalyst specific conditions where needed:
More specifically to SwiftUI, there were times that we needed view modifiers conditionally for MacOS. For this, we used an extension on view that allows us to pass in a Bool that, if true, applies the given transformation to that view. This works quite smoothly in conjunction with the Bool extension above:
And when utilised:
Making use of these extensions allowed us to tweak and polish the Mac application to get it just how we want — with a user experience that is more or less the one you would have when running the mobile version of the app.
Another challenge faced when building for Catalyst was dependencies. Some libraries that you rely on and leverage may not yet have the support for Catalyst which leads to an inability to compile the app when these libraries are included.
In our case, we use CocoaPods and needed a way to include a few pods for iOS only. If using pods, there exists a library of Ruby extensions to help you configure the pods project to achieve this. It enables you to add a function to your podfile where you can reference which pods you want just for iOS or just for Mac.
An example podfile snippet from the project Github:
The project is maintained by fermoya and can be found at the following link:
https://github.com/fermoya/cocoapods-catalyst-support
In retrospect, making this app available on Mac using Catalyst was a great learning experience for all involved. While not quite as simple as checking a box and shipping a shiny new Mac app — it comes pretty close as all of the heavy lifting done behind the scenes means that the majority of the app functionality simply works out of the box. For any remaining issues, the support and documentation around Catalyst was somewhat sparse but improving.
As Catalyst gains maturity we would expect more quirks will continue to be ironed out as well as further support and community growth that will make Catalyst more seamless and attractive in the future. Even so, we consider using Catalyst in its early stages a big win — with the ability to reach more new users and provide existing ones with greater flexibility in how they choose to power their chosen research project!
