> I would not advise a new developer to learn AppKit at this point in time.

I've been contracting on a "modern" mac app in SwiftUI for the last few months, one of the issues I see is that you can't actually get that far without AppKit right now unless you have the luxury of supporting only the latest macOS. Even then people often just don't upgrade their OS until they buy a new computer so you're stuck with whatever version of SwiftUI. It's a bit of a weird time for macOS development.

I was recently contracted to help with a (very small!) Mac app written in SwiftUI where they had hit a hard wall on implementing a couple fundamental UI features and needed that part of the UI rewritten in AppKit. "That part of the UI" is about 80% of the surface area of the apps' main window. (Worth noting that the app current deploys to macOS 12, so even the latest deployment target isn't good enough to get us there.)

AppKit may go away eventually, but _today_ it's still required to write a good Mac app even if you can use SwiftUI for large portions.

My experience on this project has also taught me that AppKit can be made to play quite nicely with SwiftUI. The AppKit code is encapsulated well, and from the outside gets instantiated and included exactly as if it were a SwiftUI component.

This essentially mirrors my experience however the codebase is more around 50-50 split AppKit / SwiftUI, most controls we tend to use AppKit and layout and display SwiftUI. I don't actually think the integration is too painful, layout can be a little weird sometimes where the two worlds awkwardly join but you can work around most issues there.

I like SwiftUI a lot, but IMO it's not really ready for primetime yet, while trying to do something partly in SwiftUI and partly in UIKit is ugly, ugly, ugly (again, IMO).

Why do you think it’s ugly? What makes it so?

I’ve bridged several UIKit components into SwiftUI and it’s been fine. You have to be careful with Auto Layout, my approach was to divide into separate UIView and then wrap those in UIViewRepresentable, thus leaving the layout to SwiftUI. But that was the main thing to keep in mind.

> UIKit via Catalyst

Catalyst is clearly an interim solution for a fairly narrow group of developers. If someone is planning on targeting macOS only then they can ignore it.

I work on a large, complex, well-respected iOS app. Some of our main competition is desktop apps, and we've often been asked for a macOS version. M1 Macs can run our app natively now, and we've done some work to make that a better experience than it would be by default. We've also spend some time seeing about using Catalyst to bring the app to the Mac for real.

As a longtime Mac developer, I'm not super impressed. It's cool to get a build going for macOS quickly, but the effort required to make a non-trivial Catalyst app not suck turns out to be very significant.

I would definitely not even dream of using it to build a Mac-first/Mac-only app. The (debatable) advantages of UIKit over AppKit are just not even close to enough to outweigh the difficulty involved in making a good Catalyst app. The benefit of Catalyst is bringing an existing iOS codebase over and/or sharing code between platforms. It is not a better way to make a Mac app on its own merits.