> how hard could it be?

The programmer's Credo:

    We do this, not because it is easy, but because we thought it would be easy.

> These damn animations man.. they're so fluid and springy and easy to use in SwiftUI, that it lures you into adding them everywhere.

That's the case with many UI frameworks. Built-in animations are a big draw. For myself, I eschew frameworks, so I have to write the animations by hand. It's a fair bit of work, but they are all supported in UIKit/WatchKit/AppKit.

Looks like the performance bottlenecks are from deep recursion. That's probably something that might be code-around-able. UIKit doesn't have as deep a recursion, but it has many other default behaviors that can result in slow performance, and a lot of my "tuning" is about finding these, and determining more optimal code solutions (like redrawing, as opposed to triggering new layouts, etc.; which isn't as easy as you might think. Sometimes, setting a variable in an instance can trigger a new layout).

I think that the idea of "code once, deploy everywhere," which SwiftUI promises, is pretty much a smoke seller's[0] dream. It's a classic. C was supposed to do that. Java was supposed to do that, etc.

I have found that I really need to write native for each platform, because the user experience is so different, that it's actually impossible to really cater to it, without delivering some lowest-common-denominator-something-just-doesn't-feel-right solution.

So, even if I was using SwiftUI, I'd still release an iOS version, a Watch version, a Mac version, etc., with specializations for each.

The thing that I like about the idea of SwiftUI (I haven't used it to create a shipping product, yet, so I don't have much more authority to declaim, than as an interested bystander), is that it allows great flexibility in the software development methodology.

If I write AppKit/UIKit/WatchKit, it really should be MVC, and not just MVC, but NSObject-based MVC. I know, I know, "But what about MVVM?". I feel that MVVM is an excellent model, but that it is not how these frameworks were designed, so they need to be sort of "kludged" to support it. I work in MVC, because they are totally meant for that model.

I'm looking forward to seeing how SwiftUI evolves, but I have yet to be convinced that it is a viable model for me to write shipping software.

It's really no hurry. Lots of major shops still write a lot of their stuff in ObjC/UIKt/AppKit/WatchKit (including Apple). It will be a number of years before we're required to use SwiftUI.

[0] https://www.tell-a-tale.com/nasreddin-hodja-story-smoke-sell...