The state of native macOS software development

Hello everybody!

I'm a software engineer with more than 10 years of experience in the backend web development world — mostly LAMP stack.

My goal for 2021 is to learn Swift and develop a native macOS app I have been thinking about for many years now.

I'm starting to look for learning materials and I found out it is quite difficult to find books, tutorials and resources in general for learning Swift for macOS development — all of the tutorials and books are focusing on iOS.

Other fellows Swift developers mentioned that Apple may want to gradually retire native macOS development and move developers from AppKit to use UIKit + Catalyst.

What are your thoughts about the state of native macOS development in 2021?

Thank you very much! — and happy new year!

Most of the non-UI related code should be identical or very similar between iOS and macOS so following iOS tutorials for that shouldn’t be a problem. Yes it is really annoying trying to search for a macOS specific problem though. I usually end up asking on the Apple developer forums.

For UI code, I would recommend you start learning SwiftUI and Combine instead of AppKit or UIKit because that will insulate you somewhat from AppKit/UIKit differences (SwiftUI is sort of cross-platform if you’re willing to #if os(...) a lot of edge cases), and will also offer a measure of future-proofing if AppKit is ever deprecated.

I will say that so far, new UI features have been coming to AppKit/UIKit first, and then showing up in SwiftUI later. To me this indicates AppKit still has legs.

1 Like

Just my ¢2: it really depends on the nature of your app but for most cases I think iOS/macOS portability is becoming easier and easier to achieve with each new OS/toolkit release. Your app may benefit from being portable especially considering that it's not that difficult to achieve. Today I develop my iOS apps by mostly running them on Catalyst for convenience of debugging, then just occasionally test them on actual phones.

Of course there are a few classes of apps that make sense only on the Mac: system/disk utilities, maybe some heavyweight audio/video/3D authoring apps - what else? Other than that I'd say try the UIKit/Catalyst path until you hit a wall and realize the app is inferior and suffers from not being 100% macOS native.

1 Like

When working with UIKit for macOS (Catalyst) you have to be aware of the limitations. For example, I was suprised to find that the Process API is not available in Catalyst even when your app is built purely for macOS. While technically you can dynamically link against frameworks compiled for AppKit/macOS from Catalyst apps, this is cumbersome, and bridging large APIs across is not very practical.

Additionally, if you need to do any non-trivial window management, current SwiftUI App/Scene lifecycle APIs are inadequate. WindowGroup, DocumentGroup, and Settings is all you can have in SwiftUI-only apps. While they allow you to manage groups of windows, you can't address any single window individually and observe its state. scenePhase also doesn't seem to work in SwiftUI for macOS. There doesn't seem to be a good way to declare your own types conforming to Scene that wrap NSWindow or any of the low-level APIs. UISceneDelegate may also be insufficient, as iOS "windowing" abstractions don't cleanly map to macOS.

I hope these issues are resolved in future versions, but currently you have to fully understand requirements of your app so that you don't need to migrate from Catalyst to AppKit in the middle of your development cycle. I personally would say that SwiftUI+AppKit is a safer bet at the moment, unless you have some substantial UIKit-only codebase that you need to bring over to macOS. At least when starting with a non-Catalyst SwiftUI app it's easier to swap SwiftUI parts with AppKit code that you know has full power on this platform and is not limited by quirks of Catalyst.

3 Likes

It's probably best to ask these questions at a forum more dedicated to Apple development, like Apple's own developer forums. You'd get a much wider audience there, I suspect.

1 Like
Terms of Service

Privacy Policy

Cookie Policy