6. Why Write a macOS App?

Written by Sarah Reichelt

In the previous five chapters, you’ve created a real, native macOS application. It looks and behaves like a standard Mac app, and it follows all the Apple guidelines.

But a lot of Mac apps are not built this way.

In this chapter, you’ll look at what distinguishes a Mac app and consider some of the alternative ways of building one. You’ll assess the strengths and weaknesses of each approach.

You aren’t going to build anything in this chapter, so skip it if you prefer to keep coding. But it’ll help you see why writing a native Mac app is such a great idea.

What Makes a Mac App?

At WWDC 2021, Apple engineers gave two code-along presentations about SwiftUI on the Mac. They started by listing the four key principles of great Mac apps:

Flexible because of the different ways we interact with our Macs: keyboards, track pads, mice and controllers. Also, Mac apps offer a lot of customizations. Look at Finder with its different view modes as well as the different parts of the window you can show or hide. Mac apps adapt to all these individual preferences.

Familiar because Mac apps all follow similar design patterns. The menus should always contain the expected items. Apps are easier to use when a window has specific zones for navigation, content, details, controls and so on, located in the expected positions.

Expansive to allow for many different screen sizes and window sizes. Your app has to work in a small window on a tiny MacBook Air, in full screen on a 36” monitor or with multiple windows spread over multiple monitors. It can do this by offering optional views that the user can turn off and on and by displaying content in a way that adjusts to suit the view size.

Precise because of large windows and the control methods. Mice and track pads are amazingly accurate, unlike a finger. As a result, controls can be smaller and more densely packed.

Consider each of these principles and how On This Day conformed with each one.

What are the Alternatives?

There are many different options for writing an app that will run on a Mac, so have a look at the main ones and assess whether they follow these key principles.

iOS Apps

Apple Silicon Macs can run almost any iOS app directly. As an example, I searched the Mac App Store for calculator, but selected iPhone & iPad Apps:

I downloaded a free app called Calculator - Free Calculator that said it was designed for iPad. When I ran it, I saw a simply vast window with huge controls, an ad at the bottom and an immediate request to give the app Bluetooth access. Why any calculator would need this is not clear.

I’ve shrunk it down for the screenshot but the window was 1800 x 2382 on my iMac:

The Preferences were interesting, especially the Touch Alternatives section. These settings are auto-generated:

Key principles:

• Flexible — no
• Familiar — no, not to a Mac user.
• Expansive — no
• Precise — no

Overall score: 0 / 4

Should you use this as a way of getting your apps on the Mac? No.

It’s a neat trick, but there is no way that an app designed for an iPhone is going to look good on a Mac screen.

If you have an iOS app and never have any intention of making a Mac version, and if you know the app doesn’t use any iPhone hardware like the GPS or accelerometer, then perhaps you could leave it available through the Mac App Store, but it isn’t going to give a good user experience.

Catalyst Apps

With iPad app projects, you can check a button in Xcode to have it build as a macOS app too. Apple uses this a lot for their own apps.

One example is the Home app. I have a lot of automated lights in my house, so this is an interesting app to me. The Home screen looks almost identical to the iPad version and that works fine.

But look at this dialog box:

This is obviously an exact copy of the iPad version with huge controls and lots of white space. The app uses the standard menu bar, but the menus aren’t showing all the items I would have expected.

Key principles:

• Flexible — partially
• Familiar — partially
• Expansive — partially
• Precise — no

Overall score: 1.5 / 4

Should you use this as a way of getting your apps on the Mac? Maybe.

If you already have an iPad app that you want to get on to the Mac without much effort, then this is the way to go. There are workarounds to make Catalyst apps look more Mac-like, and we have a book, Catalyst by Tutorials, to help!

Web Apps & Electron Apps

No Apple solution will give you a truly cross-platform app. If you need to get your app on to Windows as well as macOS, then a web app will probably be your best option. You can use Electron to bundle your web app into a standalone app that you can distribute, even through the Mac App Store.

Electron apps have a bad reputation for resource usage. If your Mac feels sluggish, open Activity Monitor. You may find your memory or CPU is busy with multiple instances of a single app. This is usually an Electron app.

However, there are some excellent Electron apps available. Visual Studio Code is a terrific app for web development.

Nobody is going to mistake Visual Studio Code for a native Mac app, but people who use it on both Macs and Windows PCs are going to appreciate the consistency.

Key principles:

• Flexible — yes
• Familiar — partially
• Expansive — yes
• Precise — yes

Overall score: 3.5 / 4

Should you use this as a way of getting your apps on the Mac? Yes, if your app has to be cross-platform.

Visual Studio Code is a great example of a cross-platform app that performs well. But Microsoft has announced that Visual Studio, their main development app for creating .NET, C++ and Electron apps, is moving the Mac version away from cross-platform and on to native macOS, so as to improve “performance, reliability, and product quality”. They have the resources to make two versions of the app and have decided that a native Mac app will provide a better experience for their Mac-using customers.

Note: Another possible cross-platform option is Flutter, which is a Google technology that allows cross-platform development. They’re moving into the desktop space, but so far this is only in beta, so I am not able to make an assessment. It will be interesting to see how it develops.

Native Mac Apps

The obvious example here is Finder — perhaps the ultimate Mac app. Certainly, it’s the most used.

Key principles:

• Flexible — yes
• Familiar — yes
• Expansive — yes
• Precise — yes

Overall score: 4 / 4

Should you use this as a way of getting your apps on the Mac? Yes.

And the Winner Is…

So now that you’ve had a look at the alternatives, should you write native Mac apps? YES!

If your app has to run on Windows as well as macOS, then you must either write two complete apps, or you go with a cross-platform solution, like Electron. Your choices are limited in that situation.

If you’re writing for the Apple ecosystem, then write a native Mac app. No other solution will give your app the true Mac look and feel. No other solution will adapt so seamlessly to different devices and input methods. No other solution will stay as modern as the OS with every update.

Users care about the apps they use on their Macs.

Setapp is an app subscription service for Macs, and they do annual surveys. You can read the full 2021 survey results yourself, but here is a quote from the report:

Mac apps make users feel more productive

We’ve also found that users prefer native apps and apps designed specifically for Mac.

Code Sharing

Once you’ve decided to write a native Mac app, you don’t have to start from scratch every time. Do you already have an iOS app? Great! You can reuse a lot of the code.

And it goes the other way too. If you start with a native Mac app, you can use it as the basis for an iOS app.

Think of all the code that went into the On This Day app. The data models, settings and data flow mechanisms are completely transferable. The main task would be to rethink the interface so it gives iOS users as good an experience as the Mac version gives to Mac users. If you merely duplicate the interface, you miss out on the unique benefits of iOS.

Xcode has a Multiplatform option when you create a new project. This sets up a project with shared files, platform-specific files and two targets:

This is a much better option than Catalyst, as it allows you to have a single project with shared code files, as well as files that are only members of one of the targets. You get the code reuse of Catalyst, while maintaining sufficient independence to create two apps, which will both be true native apps on their respective platforms.

The multiplatform template uses SwiftUI, which makes sense because SwiftUI is Apple’s multiplatform framework. But this still gives you the flexibility to insert AppKit and UIKit components as required. Some of the SwiftUI views you create will be specific to a particular platform, but others, especially the smaller component views, will be usable in both targets.

Challenge

Look at other apps you have on your Mac. Which ones look good? Which ones do you enjoy using? Which ones look like they were written specifically for macOS and which were written originally for other platforms?

Can you work out why you enjoy using your favorites?

Key Points

• There is no one tool that suits every task and every set of circumstances. You have to assess your needs and choose what will give the best result for you and your users.
• There are several different technologies you can choose for writing a macOS app.
• Only a native app will deliver the full Mac experience.
• Native Mac apps have a particular look and feel, and users really do appreciate that.
• You can start with a multiplatform Xcode project that allows for code sharing and still creates native apps.

Where to Go From Here?

The two SwiftUI on the Mac sessions from WWDC 2021 are really useful:

• SwiftUI on the Mac: Build the fundamentals
• SwiftUI on the Mac: The finishing touches

This wraps things up for the On This Day app. In the next section, you’re going to build an entirely different type of Mac app — a menu bar app.