That's basically what I was saying. SUI is a lot more flexible, than the "classic" SDKs. They require MVC, but SUI lets you use whatever model you want.
Thanks for the experienced contribution!
Still not confident that SUI would give me the app I'm developing now. It's a fairly ambitious one. Lots of moving parts.
But I am often wrong, so I'll definitely be watching this space.
And on the note of the app you are developing now.. you would be surprised! I don't often plug my own apps.. but if you look up snap web studios in the app store both of those apps are purely SwiftUI with maybe one or two UIKit bridges for the hacker news app. Eggy is ambitious from a UX perspective, and the HN app is just straight-up impressive and demonstrates that you can make complex and very fast SUI apps.
edit: also, not sure if you were aware -- but you can use observable objects & such with UIKit :P
But they are still a deviation from the model the SDK was designed for. The original Apple SDKs are totally bog-standard MVC models. If I try anything other than that, the code complexity increases a lot (especially with VIPER).
I think that a lot of these models were developed to allow projects that were really supposed to be doable by one experienced person, to be broken into something for a team of relatively inexperienced people. That's not necessarily a bad thing; but it's not how I work.
I like keeping things simple; even though it never ends up simple (See "Programmer's Credo," above).
> but you can use observable objects & such with UIKit
Yeah, but it's not really "native" support, like AppKit. SwiftUI has it baked into its DNA.
also totally agree on keeping it simple, but I spend about 6 months designing a codebase we could bring anyone up to speed on and it has worked!
iPhone 12 Pro, iOS 16.1.1
edit: would also like to note that I have been thinking about this problem for like 10+ years lol.