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
Scene lifecycle APIs are inadequate.
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.