Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I quit using SwiftUI

chsxf.dev

Post reply on HN
Print view View original

141–150 of 257 posts

Re: Why I quit using SwiftUI

#141

Post by resist_futility »

pohuing wrote: post #84
GrabbinD33ze69 wrote: post #23

Earlier quoted context omitted.

I agree, in my experience, MacOS is one of the most reliable operating systems I've used in terms of lack of crashes or spurrious bugs; the most common bug I see is my mouse pointer dissapearing, which is fixed by opening the tasks view.

If only they could so something about the truly terrible window switching crap, where you'll have to hit the same icon in your doc multiple times to eventually with a bit of luck get to the window you wanted. Why can't we have window previews like Windows has had since Windows 7 or just about every DE on Linux

Right or control click the dock icon and choose the one you want. You can also press control-down arrow key to show current app windows or up for all windows/desktops.

Re: Why I quit using SwiftUI

#142

Post by makeitdouble »

solomatov wrote: post #14

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

Perhaps there isn’t enough internal sponsors of open source initiatives now that Chris Lattner has left ? (I of course don’t think he was the only one pushing for it, but I also assume his departure triggered/coincided with other events that might not have been made public and shuffling happened in keys teams)

Re: Why I quit using SwiftUI

#143

Post by gilgoomesh »

stephc_int13 wrote: post #61

Any UI code running on a modern CPU should take close to 0ms to update, no matter how many buttons, toggles, sliders and shadows. For the rendering part, it depends, I'd say it should take between 0.5 and 2ms with many layers, a lot or transparency and not much care for optimization.

SwiftUI can be ridiculously fast – closer to a 3D framework than a typical 2D windowing framework – because it can reduce to a set of uninterrupted draw calls.

Rendering is not why SwiftUI can be slow.

If you don't know what you're doing, it's possible for SwiftUI to think your new view is unrelated to the old view and everything needs deallocation and reallocation.

Re: Why I quit using SwiftUI

#144

Post by bradgessler »

coldcode wrote: post #4
jph wrote: post #2

SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of…

It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many com…

There’s a back port of the nav view at https://github.com/johnpatrickmorgan/NavigationBackport

Re: Why I quit using SwiftUI

#145

Post by saagarjha »

bradgessler wrote: post #144
coldcode wrote: post #4

Earlier quoted context omitted.

It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many com…

There’s a back port of the nav view at https://github.com/johnpatrickmorgan/NavigationBackport

Obviously, this should be something Apple invests into itself. But they're not going to do it because their culture does not value it; actually, they're often culturally blind to the fact that it might even be useful to provide this. With SwiftUI this kind of nearsightedness really hurts the platform.

Re: Why I quit using SwiftUI

#146

Post by saagarjha »

dpmitu wrote: post #31
coldcode wrote: post #4

Earlier quoted context omitted.

It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many com…

At my company we've been slowly rewriting our UIKit app in SwiftUI. We were due for a rewrite when SwiftUI dropped. I'd say we're about 75% done. For those "stupidly complex UIs", SwiftUI just doesn't have enough hooks for customization. And the improvements are too slow. Using SwiftUI has been bitter-sweet. It feels like you just can't use it to craft a high quality app that doesn't look like a generic iOS app.

SwiftUI is an interesting toolkit. It is really good at making "generic iOS UI". But it's also very good at making something completely custom. I actually think this might be a good thing, because the UIs that people hate are the ones that pretend to be standard but are drawn by hand in ways that are not standard at all.

Re: Why I quit using SwiftUI

#147

Post by saagarjha »

jules wrote: post #58
rudedogg wrote: post #34

I'm building an IDE in (mostly) SwiftUI, and have been using it since release, so I feel like I've worked with it more than most people. A couple observations: - SwiftUI is really complex It's going to take you at least a year to get used to the declarative way it works, and be able to make UIs without struggling to figure out how to shuffle data around. If you look at SwiftUI examples/code, most of the complexity is…

How do you silo the changes? The issue was that changing a property of an object caused the inspector to be redrawn. With old fashioned UI libraries you would only change the value of one text field in the inspector. Can this be achieved with SwiftUI? To be honest I'm surprised that it's that slow even if the entire inspector is redrawn. Surely on a modern computer you can redraw a couple of text fields at 30fps?

> Surely on a modern computer you can redraw a couple of text fields at 30fps?

No, this is actually the thing you should not be doing in SwiftUI. Ideally you text fields are not redrawing at 30 fps, actually, ideally nothing in your interface is doing this except when an animation is running and even then only the components that are animating. SwiftUI makes it really easy for you to accidentally start redrawing things that don't really need to be redraw far more often then you want, and that's how you get performance problems.

Re: Why I quit using SwiftUI

#148

Post by saagarjha »

ohgodplsno wrote: post #83
bsaul wrote: post #19

Earlier quoted context omitted.

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

iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame. Android variants all have things that iOS can only dream of having in five years (notifications was a fun one), just spread very unevenly throughout manufacture…

> iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame.

This is a bit of a simplification but in broad strokes it is kind of correct. And it turns out this actually makes good UI!

Re: Why I quit using SwiftUI

#149

Post by astrange »

bowsamic wrote: post #20

I 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 appli…

Writing controllers is complicated and underspecified in UIKit and AppKit; AppKit has old unmaintained "bindings", UIKit doesn't have them at all, and it seems to lead to third parties reinventing the whole stack rather than using any of it.

Re: Why I quit using SwiftUI

#150

Post by saagarjha »

kevingadd wrote: post #90
stephc_int13 wrote: post #61

Any UI code running on a modern CPU should take close to 0ms to update, no matter how many buttons, toggles, sliders and shadows. For the rendering part, it depends, I'd say it should take between 0.5 and 2ms with many layers, a lot or transparency and not much care for optimization.

In my experience working with IMGUI-style libraries, it's definitely feasible to perform full layout and rendering for complex UI in 1-2ms at most. For simpler applications it should be basically free. It's depressing that people are willing to accept complex, slow layout APIs at this point considering it's been possible for stuff to be fast for a long time. Perhaps surprisingly, the most expensive part is usually te…

Whenever people come up with low numbers like that their mental model is really what they see as sticking some ASCII on the screen with a couple of colors blitted in. Doing text rendering that is actually good, transparency, shadows, the things that make a UI worth using makes things somewhat more expensive. It doesn't have to be overbearingly expensive–modern computers are fast, after all–but it's definitely going to be more than what you think an imgui thing is going to take. And this is pretty important when you're making an OS, otherwise you're really making something that a lot of people will not want to or be able to use.
Post reply on HN