A Mac App!
In 1984 my Dad brought home a Mac 128k, and it would define my life. After years of play, I started creating my own software. First with HTML, then Director and every other piece of Macromedia software. Since then I've worked with a ton of technologies, most of them web-based.
Until a few years ago I'd never built anything on Apple's platform, the platform I've used every day for over 30 years! What turned into Series app was the first time I'd opened Xcode and gotten anything more than the simplest thing to work.
It was a joy! After years of building backend databases and server platforms I felt like I'd come home. Graphics! Animation! User Interactions. The direct connection to the user experience brought me back to those early days of Director and Flash.
But the Mac—the cornerstone of my own computing experience—still felt out of reach. Developing for iOS uses a framework called UIKit whereas developing for macOS uses a framework called AppKit. They're similar in many ways, but also completely different. Despite the knowledge I'd built up with Series, it would be yet another huge learning curve.
Fortunately, Apple has been working on this problem. They've introduced several tools to help the massive number of iOS developers bring their apps to the Mac. That, plus the new energy in Mac hardware with Apple Silicon means this could be a great time to finally deliver on my dream of creating a Mac app.
And using Series on the Mac would be awesome right?
So the good news is Apple is working on this. The bad news is, there are several overlapping technologies to choose from each with its own set of tradeoffs. Let me attempt to explain.
Traditionally, iOS apps are built with UIKit and macOS apps are built with AppKit. These frameworks provide all of the tools to create interactive apps on their respective platforms. (Underneath these two frameworks is an enormous number of other frameworks and tools, but they're mostly cross-platform.)
Starting with iOS 13 and macOS 10, Apple introduced SwiftUI, a modern replacement for both UIKit and AppKit. However, it doesn't cover nearly all functionality especially on the Mac. Two years later (as of iOS 15 and macOS 12) it seems possible to build most of your app in SwiftUI. There are still many gaps, and when you need to fill them you have to drop down to UIKit or AppKit.
There's also Mac Catalyst which take an iOS app written in UIKit or SwiftUI and magically converts it to a Mac app. Yay! This works great for some apps, but conversions are always lossy so you're at the mercy of Catalyst for how "mac-like" it will actually feel.
The big thing to know is that SwiftUI is like 100x faster and easier when it works. When it doesn't, it's about 10x more frustrating. Choose wisely.
There's more. The overall architecture of how an app is organized makes a big difference in how easy it will be to build and maintain. I think about it in three layers:
-
Environment – this is the lowest level and works most closely with the operating system. iOS, iPadOS, macOS, and Mac Catalyst are the environments this app might run in. You don't get much of a say about what happens here.
-
Base – this level handles how the app's screens are organized and how to get from one screen to the next based on actions the user or operating system perform. This is your "app architecture" and defines how everything else comes together.
-
Views – this level is all about the individual screens and components that make up those screens. This will be the bulk of the app.
Ok so let's look at some options. For each environment I assume that Views will be in SwiftUI if at all possible. The Base layer is the big question, and changing that decision later could be costly.
iOS, iPadOS
A pure SwiftUI app would be nice, but navigation with SwiftUI can be challenging and buggy. A base in UIKit gives us the ability to mix and match more easily. It'll never be a pure SwiftUI app, but we'll have the most levers to work with.
macOS
If the base is in AppKit, the learning curve will slow initial development a lot. If the base is in SwiftUI, dropping to AppKit will be necessary so why take on that overhead? This is a tough one.
Mac Catalyst
We can avoid AppKit completely! Catalyst won't feel perfectly Mac-like, so a UIKit base will be easier to customize than SwiftUI. Still, not a real Mac app and will require many workarounds long term.
I sat on these options for a while, wondering how to even get started. Every time I experimented with an iOS + macOS app it got overwhelming quick. The differences hit right away. How will the app be organized? Tabs on iOS? Sidebar on iPad? Different sidebar on Mac? You're building three apps before you even know what one is supposed to do.
Finally, I tried something novel. I started with the simplest thing: a macOS-only project in SwiftUI. Suddenly it was like magic. I was using all of my knowledge of SwiftUI to create a Mac app! In just a few hours I had something that felt real. This was on macOS 11. A couple weeks later macOS 12 (Monterey) improved things even more.
Feeling giddy about finally creating a Mac app.
Now with a real-ish app in hand, I could start to think about the rest of the project. What is this app anyway? What are the major components? Which of them would need to be written in AppKit vs SwiftUI? Which parts can I re-use for iOS and which will need to be custom? These are all fine problems once you can line them up and work through them. I was past the blank canvas!
I spent another week filling out the app's features, adding ideas that would stretch my understanding of the project. Fast and loose at this point, more like sketching than software engineering.
It didn't take long for the app had more features than I could manage and bugs were popping up all over. That's ok! The sketch's job is done and it's time to build for real.
