I think this hides the actual pitfalls: it is possible to be lulled into thinking SwiftUI is the right tool, only to discover that a minor UI change is impossible, leaving you with little option than to dump it entirely for the component in question and rewrite it from scratch in UIKit or AppKit. It is a truism that you should "choose the best tool for the job". Yes, of course. You definitely shouldn't choose the worse tool for the job after all. The tricky bit has always been in determining which tool is best for the job. Once upon a time the answer was easy, there was only one tool, and critically, it was the tool Apple themselves dogfooded for their own stuff, so it was usually at least capable of doing most things. In the age of AppKit/SwiftUI/Catalyst, this is a significantly more difficult question, and this is ignoring things like Electron, etc. The problem with SwiftUi is precisely that if often feels like you only know if it was the best tool for the job after the fact. It requires being an expert in it before you can predict its limitations (which often are bug-related and not necessarily "conceptual"). This would maybe be excusable for a beta release, but SwiftUI is now around 4 years old.
Arguably, its original sin is simply not being open source, and on top of that is trapped behind one of the most opaque bug-reporting mechanisms in the industry. Every minor hack involves tremendous reverse-engineering, which may then have to be replicated throughout the community, instead of being a GitHub issue and PR request like in Electron for example. There are of course upsides to the closed-source model, but in 2022, you have to deliver on those upsides if you want to make a strong case for your framework. But as I've mentioned above, SwiftUI hasn't. It has none of the aura or magic of AppKit from the 2000's: a framework used by amazing apps at Apple that can get just about anything done. In fact it is the poster child of all the downsides of this model.
Arguably, its original sin is simply not being open source, and on top of that is trapped behind one of the most opaque bug-reporting mechanisms in the industry. Every minor hack involves tremendous reverse-engineering, which may then have to be replicated throughout the community, instead of being a GitHub issue and PR request like in Electron for example. There are of course upsides to the closed-source model, but in 2022, you have to deliver on those upsides if you want to make a strong case for your framework. But as I've mentioned above, SwiftUI hasn't. It has none of the aura or magic of AppKit from the 2000's: a framework used by amazing apps at Apple that can get just about anything done. In fact it is the poster child of all the downsides of this model.
And this doesn't even touch on the fact that Apple seems to repeatedly demonstrate that they don't take these technologies very seriously:https://twitter.com/stroughtonsmith/status/15294383578346332...