Past, present and future of native macOS app development

In the beginning was Cocoa. Well, maybe not at the very beginning of time, but at least it was there when I began to learn macOS app development. It's still here, and it doesn't look like it isn’t going anywhere soon. But let's not get ahead of ourselves. In this blog post I wanted to give you a potted history of macOS development, and tell you a little about the direction in which it’s heading. We will go through Mac Catalyst, Apple Silicon and of course SwiftUI.

What is Cocoa?

First things first. What exactly is Cocoa? Let’s get technical for a moment. It’s an object-oriented API (Application Programming Interface) developed by Apple to make writing desktop apps possible. It is a successor of Carbon, C-oriented API used in 32bit Macintosh machines. It gives developers all tools needed to build applications with Graphic User Interface working on all macOS devices.

It contains a few frameworks that will provide you with essential data structures (like lists, dictionaries, and sets) and types (numbers, strings), files support, and user interface components ready to use in your application (buttons, windows, labels). These UI components are contained in a framework called AppKit. On iOS/iPadOS/tvOS, we have a similar API called Cocoa Touch, but it includes a framework called UIKit instead of AppKit.

So those are the technicalities. It was crucial to introduce you to that AppKit and UIKit concept because they differ between iOS and macOS applications. If you think about it carefully, it's pretty obvious. iOS and macOS look different, so they can't use the same component for UI. The question is where this split will happen and who will be responsible for implementing it.

What’s the current situation?

Currently, app developers are responsible for preparing separate UI and between-screen navigation. Business logic can be shared between mobile and desktop if it's separated from platform-specific data. But still we have two separate user interfaces to maintain.

This separation is both good and bad. It will ensure that desktop applications aren't a copy of the mobile app, but the macOS environment lacks many great apps available on iOS.

The number of iPhone users dramatically exceeds the number of macOS device owners. So it's not surprising that when you are thinking about a new application, you will build it for iOS.

Apple realised this too, of course. That’s why, two years ago, they introduced the Mac Catalyst.

Bringing iPadOS to macOS - Mac Catalyst

Mac Catalyst will allow you to run the iPadOS app on Mac. It's a natural first step to unite all platforms. Following its marketing slogan, "Your next computer is not a computer", the iPad became the first device of choice for light work and content browsing.

Personally, for my development work, I only use MacBook and Mac Mini. Text writing, web browsing and learning all happens on iPad Pro. iPad applications are more advanced than their iPhone equivalents and are already displayed well on a bigger screen. So engineers from Apple allow you to run your UIKit code on macOS by just switching one option.

The burden of handling application UI on different platforms shifts from app developers to Apple. But can it be even better? Of course it can.

Bringing iOS to macOS - Apple Silicon

With the inevitable shift from Intel-powered macs to devices equipped with Apple ARM processors called Apple Silicon, all Apple devices will work on similar hardware. That way, you will be able to run iOS applications on macOS without a need for Simulator. This transition has already begun, and you can opt-in to make your UIKit app available on macOS. This solution is similar to Mac Catalyst but backed by proper hardware - it can be done more efficiently. But I have some concerns about this. iOS applications are prepared and tailored for the small screen. How will they look and behave in a large, multi screen environment? We will see within a year.

Having read this article so far, you might be asking yourself - should I write just an iOS application? What should I do if I want to have a different look and feel for my application?

SwiftUI - learn once, apply everywhere.

Two years ago, at WWDC, Apple presented a new way of writing a UI. It's based on Swift, it's platform-agnostic, and it's called SwiftUI. We moved from object-oriented Objective-C UIKit and AppKit to a declarative framework in Swift. With this year's addition to SwiftUI, it's pretty evident that it will soon become a default solution to write a UI code for Apple platforms. And it can be used to write multi-platform code. But here you will go one step back from Mac Catalyst, and Apple Silicon solutions presented previously.

It's true that SwiftUI introduces new essential components to use instead of UIKit or AppKit views, and they are the same on each platform. But the philosophy of SwiftUI is: learn once, apply everywhere. Each software platform contains its specific elements, and that way, it can't be used on others. But the paradigm used by SwiftUI is always the same. That way, we can share more small components between the platform, and only a chunk of the codebase has to be written separately.

But Cocoa isn’t going anywhere

At the beginning of this article, I mentioned that Cocoa isn't going away. This statement came from my experience from writing native macOS apps - first with Cocoa, and now I rewrote it in SwiftUI.

It turns out that in the current state of SwiftUI, it's impossible to avoid using AppKit in some parts of the app. But I don't want to discourage you. This interoperability is very easy. You can insert a SwiftUI View in AppKit View with just a couple of lines and vice versa. If you were thinking about a multiplatform app in the Apple ecosystem, I strongly encourage you to start writing in SwiftUI. You may be impressed by how easy it is to separate your code into the shared part and then use it in both iOS and macOS applications. If you are thinking about a multiplatform app for all ecosystems, you should probably look at Flutter. But this is a separate story. If you would like to read more about Flutter, take a look at our blog posts below:

6 reasons why you should try Flutter as an iOS developer

Is Flutter good for your business?

To conclude

During the last couple of years, Apple created several opportunities to increase the library of macOS applications. You can run applications from iPad using Mac Catalyst, iOS applications on Apple Silicon powered Macs, or use SwiftUI - a framework for creating apps on multiple platforms. The near future will show us the results of Apple's efforts. Hopefully, we will see more top-rated mobile apps on our desktops, but maybe it will also impact the number of desktop-grade apps on mobile, especially on iPads.

Looking for an experienced team to bring your digital product to life?

Get in touch for a free consultation on hello@10Clouds.com. Our friendly team will get back to you within one working day!