> 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).

SwiftUI is designed in a way where deep recursion is a "happens once" problem. There is a lot more compiler trickery going on than people realize, and SwiftUI actually has a very good idea of the entire hierarchy and attempts to efficiently work on said hierarchy -- the cleverness of their algos may not always be clever enough however.

> 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.

this is a very common misconception I see passed around a lot, SwiftUI is more like react-native "learn once, write anywhere". You can have universal codebases with SUI but that is more the exception than the rule ime.

> 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.

this is what most people do, you can have a common logical core and entirely different SUI frontends.

> 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.

this is a strange addition to the entire subject. you can write things as MVC with SUI, that is essentially what observable objects do. You can also easily bend them into MVVM. I don't use either approach, and instead go the Flux route.

> 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.

I have had apps featured by Apple that are SUI only, I have shipped SUI only apps to literally 300,000 users.. and I have also shipped UIKit apps to millions. A few things I have noticed is:

1. We have far less crashes than any UIKit app we have ever shipped. 99.8% crash free range with my current work.

2. Developer velocity is insane, between two people we have no issue with shipping everything that was asked for and more which leads me to...

3. It has lead to far more collaboration with design teams since we can jam on design together!

I chose react-native for similar reasons when I worked at Chime. But the moment Apple dropped their own.. I knew it was the only way forward.

Edit: also wanna add that many things in SwiftUI are simply bridged to UIKit or AppKit anyway. Maybe that explains some performance issues. But from literally all of my experience it just has been people with a poor understanding of efficient declarative UI development. A problem that affects all declarative UI dev.