I’m baffled as to how this has been so downvoted. It’s just a fact. Been using SwiftUI for two-some years and while I use it for prototyping, when I actually want to get ‘real’ things done, I go back to UIKit quick as a bolt of lightning.
I wouldn't describe it as a "fact" that SwiftUI is a toy
I have used SwiftUI now in 5 shipping iOS applications and one internal macOS app. Two of them had codebases that extended all the way back to pre-ARC Objective-C! One app was 100% SwiftUI (with two UIKit exceptions where I had to drop down to work around a SwiftUI bug)
I get "real" things done in both UIKit and SwiftUI. It is trivial to host a SwiftUI view in UIKit, and it soon becomes the most pleasant part of the app to work on in my experience
It's simply a tool to use alongside UIKit, and it happens to be fun to use too
> It's simply a tool to use alongside UIKit, and it happens to be fun to use too
exactly. the way i look at it is like a super powered version of xml (xib) for describing app uis
there are alot of things you cant do in pure xml/xib and the same is true of swiftui, in those cases you need to use an island of imperative code (uikit or custom class) and things work smoother in those cases
I’ve found SwiftUI to be a dramatic improvement over storyboards or view controllers for managing state and flow. Sure, for some view components you need to drop down into UIKit to do some detail work, but then it can be abstracted back into SwiftUI.
I have production apps in the store with SwiftUI so it's not a fact at all. These are non-toy apps. UIKit is more mature but it hasn't matter at all in my experience.