Catalyst or SwiftUI Multiplatform?

It's your decision and there may not be a single correct answer.

But if you learn SwiftUI more deeply, you will soon find...

• What can be done in UIKit cannot be done in SwiftUI

• What is easy in UIKit is very difficult in SwiftUI

So, I do not think this is true:

Catalyst is for older UIKit based apps while SwiftUI is a complete replacement for UIKit+Catalyst.

If you have enough experience to write an iOS/iPadOS with UIKit, Catalyst may be a good option to write its macOS version, even for new apps.

If you can be free from thinking in UIKit, SwiftUI would be the right future.
But it may not be the right present for us all.

Hope you can make the right decision for you.

I just went through this. At first the multi-platform seem the “right” way to go. But, multi-platform means your SwiftUI code is heavily peppered with #if os(iOS) since so many of the view modifiers for navigation do not exist on the mac. You are really irking in APPKIT and UIKIT in multi-platform. For my use case WAY more work than catalyst. The only reason I see for multi-platform is if you want to look like a Mac app, and basically have two different UIs. Or you need something not available in catalyst.

There are changes to Catalyst where iOS elements can take on macOS like appearances in BigSur as long as you flip the toggle that makes the Mac app macOS 11 only.

For this reason, I will exclusively be using SwiftUI + UIKit + Catalyst for making my iPad/iPhone/Mac apps. Though SwiftUI-only is tempting for apps with simple view structures, I’ll probably wait for SwiftUI 3 or 4 before really diving into it.

For simple views that would require a lot of UIKit Boilerplate, swiftUI is great and easy to display in UIKit-land via UIHostingController. For highly animated interactionS I’ve started to drift to SwiftUI as well, as you can accomplish more animation magic with less code. Maybe even avoiding all that UIPresentationController logic all together.

Like a user said above, swiftUI easily solve problems that are difficult in UIKit, and UIKit can provide control and power that SwiftUI abstracts from you. My goal at the end of the day is to write less code. Less code is easier to maintain!

Thanks - I think I may end up doing everything in UIKit and use Catalyst to port it over to the mac in the end. Being able to use SwiftUI controls here and there (along with the UIKit swift only code) would aid just enough to be able to write controls that somewhat work on all platforms without additional work (simpler controls there an #if os() directive isn't necessary).

I actually spent a few weeks in SwiftUI earlier this year, only to come to the conclusion @OOPer did - it soon becomes incredibly difficult to get around SwiftUI limitations that are otherwise a few lines of code of UIKit. There are other issues with UIHostingcontroller that seem to be still present in iOS 14 - bugs around safe area insets, especially when you mix UIKit CollectionViews and SwiftUI content views. Sometimes your content will get safe-areas added (via the UIHostingController) that aren't easy to remove without relying on swizzled methods and other ugly hacks.

This year's SwiftUI brings a boat load of improvements, but yes, I think it would make more sense to wait for SwiftUI 4 or so before I consider it again. Our application in question is a pretty non-traditional, highly customized app with almost everything about the UI a custom look. SwiftUI may not be the right choice here since it abstracts away a lot of the complexity at the cost of flexibility.

We've got an Obj-C mac app that we're considering to re-write, perhaps now in UIKit and later port it to macOS 11 only via Catalyst.