With Catalyst and SwiftUI multi-platform, should you create a macOS version of your app?

With Mac Catalyst and SwiftUI support for macOS, Apple has been pushing new tools to the community for the past couple years to create new services on Mac computers. Does it mean you should do too? Here are couple things to consider first.

During WWDC 2019, Apple released Mac Catalyst for developers to turn their iPad version compatible with Mac. The same year, SwiftUI was released and introduced a whole new world of possibilities.

I don’t think it’s random that Apple pushed so many new tools to help build apps for Mac. After all, its App Store is a multi billion dollar business. Wouldn’t it be great to consolidate its macOS version by attracting the developer community with great tools? That might just work.

So back to us. Assuming we have an existing mobile app, should we consider creating a macOS version to get to this potentially new users?

As usual, I think it depends. Let’s see what to consider before rushing anything.

User Experience

First thing to consider is the User Experience. By creating a macOS app, do we enhance anything in the existing service? Do we actually take advantage of using a native device rather than a web platform?

I believe it’s important to create an app that feels home on Mac. Like any other software on Apple device, users are used to a “first class” experience, so it’s important to move towards the same goal.

MovieSwiftUI has been a reference since the early days of SwiftUI of how to successfully develop a multi-platform app.

Nobody wants a half baked app that takes too much memory or that hardly resize its window, poorly handled shortcuts or Mac behaviors like the classic drag & drop.

If you already have a website that already does it all and you can’t see a real improvement in the User Experience, then maybe it’s not the best fit to start this adventure.

If, on the other hand, you feel that having access to a powerful computer can really make a difference to your app, like a picture/video editing tool, then go for it! Netflix would be another great candidate for a native macOS app.

Development Cost

Shared code across platforms doesn’t mean new platform comes at no cost.

“Great, we can reuse code all our code, right?”.

Definitely not.

If your project wasn’t optimized and designed for it, it’s hard work to get it ready for multi-platform. And once you are there and release a macOS version, remember it’s as much work you’ll need to support and maintain over time.

Some businesses removed their support to iPad for the same reasons: they didn’t have the capacity to support it in the long term and the effort for it was higher than the reward. Creating a poor tablet experience causes frustration to their developers as well their customers. It turns out to be a lose lose situation.

So if you choose to move forward, make sure you can go the distance.

App Usage

If it’s common for iOS users to browse the App Store and install / uninstall apps, I believe the same behavior is not true for Mac.

You can ask yourself the same question. Do you remember when was the last time you installed an app on your iPhone? How about your laptop? For me, it has easily been weeks or months.

If you managed to get your user installing your macOS app, chances are it will be for a long time. I don’t think many users clear their programs on weekly or monthly basis.

In short, mac users could be there for the long term (or longer than iOS one), so let’s make their first experience the best one.

RedditOS has been a great alternative to Reddit website.

New Market

Finally, before rushing into the design and development of a macOS app, it might be interesting to look into platform usage breakdown. Would it be new users joining or existing users moving from another platform (iOS, Android or Web potentially)?

It’s important to understand it as it could also backfire and split existing usage into 2 platforms rather than creating new one.

In conclusion, bringing your app to macOS can be really exciting but it can come with complexity and cost, so it’s good to get ready for it.

Let’s also remember ourselves that when the first iOS SDK was release in 2008, every company wanted to turn their website into app, as irrelevant as it could be.

Today, I think we need to be more careful about these decisions and make sure if you move forward, it’s acknowledging your user’s expectation.