I spent only about half an hour with Swift UI to decide it was bot worth it. Looks sleek but the underlying technology is too complex IMHO.
Why I quit using SwiftUI
11–20 of 257 posts
Re: Why I quit using SwiftUI
#12The post didn't go into much detail as to why it seems to be so slow. Is SwiftUI recreating an entire UI's worth of components when a state update happens?
To me that’s the red flag. That an experienced game developer wasn’t able to properly troubleshoot down to the correct level, but ended up facing a black box and gave up.
Re: Why I quit using SwiftUI
#13The author talks about SwiftUI on macOS, which I also find to be much much more buggy than what's on iOS.
Very unexpected things happen, like items in a specific region in the App UI stop responding to clicks next time once you interact with them.
However I find it fine on iOS and the issues are usually around Apple changing something in the behaviour of the UI or API and breaking it, then you need to fix it for specific versions of the iOS. That's what you get when a framework is not mature yet, I guess.
That said, I don't think there's a turning back. It might be buggy but it definitely feels like the right way of building UI.
Oh, about the performance, you can build very sluggish or very responsive UI with SwiftUI because there's a night and day performance cost difference between "re-calculating and re-drawing" the UI and adjusting a property of it. Always try to structure your components in a way that changes happen by changing passed values instead of inserting or re-doing the views.
SwiftUI works quite a bit like React, many performance lessons from React will translate into SwiftUI.
Re: Why I quit using SwiftUI
#14What surprises me the most is that Apple didn't open source it even many years since unveiling has passed. It doesn't look to me that they have any risks here. The library could be used only on Apple platforms. It will let users submit fix PRs, and make debugging code (by framework users) much easier.
Re: Why I quit using SwiftUI
#15The main issue with SwiftUI is sheer lack of maturity.
People don't think about it, but UIKit now has ~15 years of effort put into it, and got a serious boost from its shared roots with AppKit (even though big chunks of UIKit were freshly written, its structuring and API design were largely informed by AppKit), which has history tracing all the way back to the 1980s. Of course something as fresh out of the oven as SwiftUI is isn't going to be able to compare in terms of polish or capability.
So for now I'm sticking to UIKit in the apps I'm responsible for. I think SwiftUI's day in the sun is coming, but it's not here quite yet.
That doesn't mean that there aren't issues with how it's being engineered and documented, though. It has serious shortcomings that need to be shored up, and hopefully that happens with its maturation.
Re: Why I quit using SwiftUI
#16> I profiled the whole thing and discovered several things. First, the view provided by the selectable object was completely recreated with every redraw. I gained some performance back by caching it, but things remained barely usable. That... is exactly the same thing with React. You don't notice everything is redrawn until suddenly everything is unbearably slow. And then it's useMemo etc. galore. I'll withhold my ju…
IMO, you shouldn't use React-like tools in performance critical UI code. Direct DOM manipulation in such cases is much better and more maintainable option. I.e., it's easier to maintain straightforward direct DOM manipulations than all the tuning around making a React-like system more performant.
Re: Why I quit using SwiftUI
#17If I was to build a new mobile app using a shiny new declarative framework, I’d rather use Flutter, because at least that provides the benefit of targeting Android for free. Depending on the type and scale of the app, of course.
Re: Why I quit using SwiftUI
#18People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions)
I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff.
Re: Why I quit using SwiftUI
#19People nowadays praise Apple for their hardware, mainly their silicon - not their software. Maybe it's time for Apple to shake things up and promote someone else to VP of Software engineering?
I’m with you, however mac os remain the best dekstop OS and iOS remain the best mobile one, even after all those years. So, they must be doing something right..
Re: Why I quit using SwiftUI
#20I just don't get what purpose it really solves over UIKit. Everything seems far more complicated in SwiftUI, and the data dependence problems it solves did not ever really seem to be a huge issue in UIKit anyway.
Apple's sell for SwiftUI was "it's like going to a chef who knows how to cook for you" instead of "cooking yourself". But is that really a good thing? Do we really want to be taking less control of our applications when we write them?
The worst part is all these tutorials that have to combine SwiftUI and UIKit because the former is very buggy in certain cases, like navigation trees on iOS have really janky animations using SwiftUI. So you have to coordinate all your Views using UIKit. It just seems barely easier to use SwiftUI most of the time.
EDIT: Basically, in summary, it seems like a very complicated (look at the crazy language features they had to add for it) plus very opaque ("it magically does it for you just how you wanted") way to write the same apps you were already writing fine in UIKit and AppKit