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

51–60 of 257 posts

Re: Why I quit using SwiftUI

#51

Post by DelightOne »

GrabbinD33ze69 wrote: post #23
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..

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.

My mouse pointer also disappeared for a time when it by accident crossed over to my iPad. After disabling that feature it never happened again.

Re: Why I quit using SwiftUI

#52

Post by diffeomorphism »

elpakal wrote: post #5
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…

> but at the same time the docs are terribly lacking at how to handle any kind of edge cases. I agree that Apple’s documentation needs help (this year’s improvements are a nice step) but can we really expect them to provide extensive documentation for handling edge cases (you’re telling me UIKit docs offer that)?

That sounds very different from what was written? The complaint was about "lacking ... any kind of" yet you write about "extensive documentation".

There obviously is a trade off with how much you can/should expect, but "you cannot expect 9/10" is not a valid reply to "it currently is 3/10".

Re: Why I quit using SwiftUI

#53

Post by sofixa »

mrtksn wrote: post #38
guelo wrote: post #33

Earlier quoted context omitted.

Tying the SwiftUI version to the iOS version is seriously asinine. In the Android world Compose is a regular library so devs can pick the version. That's partly why there has been much more adoption of Compose even though it was released years later than SwiftUI.

I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.

It's probably the same as the technical justification for why Safari updates are bundled with iOS and not separate, why XCode only runs on macOS, why no other browsers are allowed on iOS, why macOS can't have separate scroll directions between mouse and touchpad and many many others. It's Apple's ecosystem, nobody is asking you, you're holding it wrong.

Re: Why I quit using SwiftUI

#54

Post by worik »

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.

They will be embarrassed, perhaps, about code quality

Re: Why I quit using SwiftUI

#55

Post by worik »

solomatov wrote: post #29
jollybean wrote: post #22

Earlier quoted context omitted.

Then why use it anywhere? I have never fully bought into this notion that the components should rebuild themselves in this kind of stateless manner. I think this like an intellectual obsession with functional programming mapped onto the UI Tree. I can't fathom why it's 'better'. The reactive aspects of the middle tier of the program - that's progress. But the reactive components, I'm not sure about that.

>Then why use it anywhere? To write code quicker, and make it easier to maintain. If it's a moderately complicated UI, then I could code it up much faster in React (my guess is around 10x). IMO, React isn't about functional programming, it's just a good DSL for writing UI.

> To write code quicker, and make it easier to maintain.

It makes the easy things easier. A common problem for these sorts of tools. It is help with the hard things that we need.

Edit - I have experience with SwiftUI not React.

Re: Why I quit using SwiftUI

#56

Post by worik »

Someone wrote: post #39
bowsamic wrote: post #28

Earlier quoted context omitted.

There is no evidence to suggest that Apple are deprecating AppKit and UIKit

Supertankers turn slowly, but if the captain tells you the ship will turn, you better believe it, even if you don’t see the ship turning yet. Having said that, even though Apple indicates it will turn, it still may change its mind halfway through.

> but if the captain tells you the ship will turn, you better believe it,

What Apple says at their circus show is not the same weight as the captain of a ship telling you the ship's course.

Re: Why I quit using SwiftUI

#57

Post by elpakal »

diffeomorphism wrote: post #52
elpakal wrote: post #5

Earlier quoted context omitted.

> but at the same time the docs are terribly lacking at how to handle any kind of edge cases. I agree that Apple’s documentation needs help (this year’s improvements are a nice step) but can we really expect them to provide extensive documentation for handling edge cases (you’re telling me UIKit docs offer that)?

That sounds very different from what was written? The complaint was about "lacking ... any kind of" yet you write about "extensive documentation". There obviously is a trade off with how much you can/should expect, but "you cannot expect 9/10" is not a valid reply to "it currently is 3/10".

well thats good because I didn’t say “you cannot expect”, did I?

Re: Why I quit using SwiftUI

#58

Post by jules »

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?

Re: Why I quit using SwiftUI

#60

Post by tadfisher »

pixel_tracing wrote: post #10

The entire view shouldn’t be redrawn but certain views only (not the entire tree) maybe look into prevent entire view from being redrawn itself (React does this too and you can prevent redraw without utilizing useMemo by understanding it’s internals)

Compose bakes this into the framework at the function level. By default, if the function parameters are immutable and the function doesn't return a value (basically emits compositions by calling other Composable functions) the entire composition is memoized and the function can be skipped.

The tricky part is knowing what is immutable, because standard JVM collections are not.

Post reply on HN