The odd thing is that UIKit can easily be transformed into a much more pleasant experience if you just fix some of the worst API’s, like embedding ViewControllers and adding constraints in code.
SwiftUI After 7 Years
241–250 of 343 posts
Re: SwiftUI After 7 Years
#242Death by a thousand cuts. First the tech community screamed about memory leaks, so they bolted ARC (automatic resource counting) into Cocoa since unlike C++, Objective-C had no RAII. With swift to be compatible, they forced ARC to all objects. To make RAD (rapid application devolpment), they forced InterfaceBuilder onto the dev community, where artists do layout, but engineers do code. With variable sized screens, RAD tools add constraints to layout, since artists do gui, not engineers. To support Retina displays where GUI is x2, two sets of constraints were added. Spaghetti after twine after hack after crap.
All this goes away if you use a language with RAII, dont treat your devs as morons that cannot manage resources, and allow procedural GUI - let smart dev fix layout and pixels per inch. Artist can create mockup screens in photoshot or after effects, devs do actual procedural coding.
But no, we’ve gone the LEGO assembly way to avoid hiring smart devs.
Disclaimer - I do graphic engines with GUI toolkits for a living.
Re: SwiftUI After 7 Years
#243Earlier quoted context omitted.
> But 1/ it’s much simpler for doing simple things and 2/ we can drop down to AppKit when needed. New things (especially 12 years on) shouldn't be "do simple things simpler, and drop down to old ways for complex stuff". It should be "do complex things simpler".
I strongly disagree.After many years in software development, I'm sick of resolving the same issues all over again.Make me write less code, make me spend less time fixing it.That's what is increasing productivity and scope for my projects.
> I strongly disagree.
You strongly disagree with what? That new tools shouldn't just make simple things simpler?
> Make me write less code, make me spend less time fixing it.
But that's exactly where SwiftUI fails, doesn't it? The moment you step outside the "the only UI you can do is lists", you are exactly in the "write more code with weird failures" territory with "just fallback to AppKit for anything even slightly outside of the extremely limited sandbox".
Re: SwiftUI After 7 Years
#244Earlier quoted context omitted.
Thanks for those links! Some of it was great reading. What is your thesis then? What is UI?
"A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter." https://web.archive.org/web/20090424042645/http://heim.ifi.u... View and model are related , but neither is procedurally dominated by the other. The view is not a subroutine of the model, or vice versa. They are related entities that communi…
Interesting, will check that out!
My working thesis is that UIs are basically video games. Just a gut feeling I can't really 100% put in words.
But essentially they're the same thing: Read input, update model, render view.
Re: SwiftUI After 7 Years
#245Earlier quoted context omitted.
Shaders compiled at startup vs. not, not “who knows why a repaint is happening”
It was a bit more than that, including how out of place it looked in fruity platforms.
No, they did not change the renderer because of Apple. That is a complaint about Flutter, the iOS-aping widget set can't stay up with current iOS, and I don't think they have a real solution yet. There's something about pulling out the Material UI library from Flutter itself that's supposed to help (I don't quite understand why, modulo "we can make a focused team work in a package instead of in the big ol' framework and that'll be easier")
Generally, it is not young web devs fault that SwiftUI exists, and certainly not their fault it still has serious issues 7 years in. The things named in the article as not-working in SwiftUI do work in fine in the others.
Re: SwiftUI After 7 Years
#246Earlier quoted context omitted.
I remember this video, from way back. Then, it was impressive, but it also felt logical that machines of that era were able to do it. So it wasn't magic. Just good engineering. Now everything is jank & stutter and my 64GB 25 times more powerful machine just refused to play back a YouTube video in my Safari tab since I have too many windows open.
My base 2019 macbook pro 15 on Mojave is actually faster than new macbook pros today on some tasks. There’s no way Apple doesn’t know about that internally. So I don’t see any other explanation… other than a lack of care, or a bozo explosion.
Which tasks ? I don't believe your claims.
Re: SwiftUI After 7 Years
#247Earlier quoted context omitted.
Yeah I don't really understand their insistence on these videos. I don't have the time to watch an incredibly hard to watch present babywalk me through the code, hoping I'd catch one modifier I missed that fixes the issue. Just write some docs for god's sake.
They update the docs every year. The videos are for people who want a demonstration instead of reading docs and trying things manually to see the result.
There are lots of detail in the videos that are never mentioned in docs
Re: SwiftUI After 7 Years
#248SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps. 1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each m…
Just a couple points because your opinions aren’t wrong, they’re just your lived experience. 2. There’s no magic here. There is poor documentation. The biggest trick — small views, think about what values are going to trigger a refresh. Avoid cascading view refreshes. 6. You might have missed a couple big iOS releases (iOS 7 was one to remember) where many of our apps fell over in UIKit. Swift was another ‘DOA’ for Y…
The magic is when you use things like @State or @Published and system does bunch of things hidden behind the scenes that the developer has no idea about. Then, when issues arise, the developer is unable to debug because they have no idea how these things work and what they really do.
Re: SwiftUI After 7 Years
#249This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc. Data Flow: The author claims there’s no way to know when things update. Not only does experience help…
"@environment is super cool" Strong disagree on that. @environment is an amateurish hack, basically sugar-coating global variables as a solution to SwiftUI's poor design. I had a strong background in UIKit; then for a product I'm building for myself, I decided to go all-in on SwiftUI. This was after it had been around for four years or more. SwiftUI turned development, which I used to enjoy and feel good about, into…
I don't want to downplay your lived developer experience, I'm not fully following all your arguments but let me just say @Environment is a great tool. We've all used singletons, even more so in UIKit seeing how unintuitive key value observation was.
It's used a few different ways in the app I'm looking at now. One is to hold a source of truth for my API data models. This way I have a cache of say User that, when it changes for whatever reason - maybe invalidating the cache (read logout) or changing a profile image - is handed around to all my Views that need User info with @Environment(\.user)
Same thing with my analytics. Something like a MixPanel is only going to be created once. It's a singleton. You pass it around in an @Environment.
NavigationStack was a problem pre-iOS 17 and even a bit of a jam in 17 -> 18 and was glad to drop that version. But passing around an enum of values makes deep linking intuitive, yes there's a bunch of boiler plate - setting up an enum I guess - but deep linking was never easy. If you're not doing deep linking then a NavigationPath is really simple to use but I assume that's not what you were talking about.
I used MVVM for about 6 months and ripped it out. There's no reason to use that pattern in SwiftUI. It was popularized by certain iOS evangelists and caught on with the newbies (myself included). Your reaction to MVVM and useless ceremony is exactly the response you should have to a code smell that doesn't belong and it was mine too.
Re: SwiftUI After 7 Years
#250Earlier quoted context omitted.
I am talking about virtualized lists. And it should be a framework feature. I used to use WPF on desktop, and it had pretty good virtualization support (though the framework in general was more like Angular) - most containers had virtualization support, and you only had to implement the logic on the data source, and they framework created and managed physical UI elements for you, and managed the mapping so it seemed…
I mean, it's not quite that easy. The web is a lot more dynamic than WPF. If you just want virtualized homogeneous lists, there are libraries for that (and grids). But, once you start hitting things like differently sized elements, search and so on, you start running into platform limitations that you won't be able to resolve in React land.
I know, that's why I said, that when you hit things like that (state that is too big to pull onto the client at once, and/or displayed at once), React's (and I guess a lot of other immutablity-based frameworks') dataflow management stops being magic, and you have to start tending to it.
Which usually means this model loses all advantages compared to simple MVC, or imperative systems, and at worst, becomes another headache as implementation details start leaking.