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

SwiftUI Defaults Considered Harmful

tonsky.me

Post reply on HN
Print view View original

121–130 of 135 posts

Re: SwiftUI Defaults Considered Harmful

#121

Post by mattste »

I recently started a SwiftUI project and this is a very accurate take based on my experience.

How I spend my time in SwiftUI: 1. Wondering how I can get some conditional logic. Coming from React, this is a major issue that needs to be addressed. 2. Figuring out where and what the error actually is. 3. Restarting Xcode for my view to magically start working again.

The two-way data binding is a blessing and a curse. I like React's method of passing callback functions to keep the state logic separated. This comes up with me when working with sheets.

I see the potential. I like having an all-in-one experience that IDE + framework integration provides but the poor defaults and breaking bugs really make me question the execution.

Re: SwiftUI Defaults Considered Harmful

#122

Post by saagarjha »

myko wrote: post #118
saagarjha wrote: post #44

Earlier quoted context omitted.

Very few, I’d expect, but for my target audience (students) I’d expect it to be biased a but more in that direction. It’s not a huge amount of extra work (just condition all the new code) so I’ve just keeping the requirements the same.

> I’d expect it to be biased a but more in that direction. You should be able to get pretty exact numbers for your app in AppStore Connect. The results might surprise you. Typically we have way faster adoption in our apps than the trend. YMMV.

About 90% iOS 13, 7% iOS 12, and a fraction of a percent for the remaining. I guess that's better than I expected…

Re: SwiftUI Defaults Considered Harmful

#124

Post by Iwork4Google »

To the person who wrote this, I would suggest SwiftUI is not for you. Please just go back to writing Objective-C or learn some good ol' UIKit. You can then have full control over whatever color you want your buttons to show up as, and where to have them show up, and with whatever padding you like, and as a bonus you can use commas and all kinds of great additional syntax all over the place. (I think what SwiftUI is for, has largely flown over your head).swiftly

Re: SwiftUI Defaults Considered Harmful

#125

Post by kllrnohj »

013a wrote: post #96
diffeomorphism wrote: post #20

Earlier quoted context omitted.

Haven't we been going in the other direction in recent years? With integrated title bars in browsers, custom css, fonts etc.. Chrome on Windows, Mac, Linux etc. always looks like chrome but not native. Similarly webpages look "exactly like the designer intended" even if it is a very bad fit for your device. We used to do things generically, but changed to prescribing every little detail and this now breaks when our a…

We did use to do things generically, but more-or-less the wrong kind of generic. Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc. Of course, devices got better. That set grew to ldpi, mdpi, hdpi, xhdpi, xxhpdi, and xxxhdpi. There's also tvdpi for televisions. It was supposed to be generic. It becam…

> Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc.

This example doesn't really work. Those buckets have always been primarily for image asset selection, not UI declaration/layout. It's comparable to the 1x, 2x, 3x that exists in iOS land.

Nothing has ever actually replaced those. In any UI toolkit. Vector assets finally took a chunk out of their usage, but there's still plenty of assets that are not vectors.

The density support in Android largely remains the gold standard. The only UI toolkit that actually achieved robust density independence. There's plenty broken about Android's UI toolkit, just this isn't one of them.

Re: SwiftUI Defaults Considered Harmful

#126

Post by dmitriid »

jmull wrote: post #108
dmitriid wrote: post #102

Earlier quoted context omitted.

The author is also the author of Clojure/script libraries Rum snd Datascript. He knows what declarative means very well. Swift UI creates a mess of special cases pretending to be declarative, and does a poor job of it.

He's suggesting he ought to be able to use imperative Swift control flow constructs in the declarative SwiftUI DSL. I suppose I can't really know exactly what his confusion is, but that just doesn't make sense.

It does make sense. Because SwiftUI creates special constructs for regular language features (if, foreach) despite those features, you know, being available in the language.

Re: SwiftUI Defaults Considered Harmful

#127

Post by KurtMueller »

5cott0 wrote: post #33
bouke wrote: post #18

Observing the launch of SwiftUI as a bystander (I'm not developing for any Apple platform), it seems that people are very excited about SwiftUI, but also get burned by it a lot. This is mostly Apple's fault by releasing this framework without any caveats. But the framework is more like an early alpha, not to be used in production. Tooling is not yet ready, documentation is not yet ready, heck even Swift –the language…

Actually this a very common practice for Apple and well known among seasoned devs. Apple’s shiny new things don’t really belong in production apps until a few major versions in. In my decade of iOS development experience prevailing wisdom has been that nothing has ever worked until at least a few major versions in and don’t belong in production apps unless you really love rewriting your entire codebase. Good rule of…

Wouldn't Combine be the official competitor of RxSwift?

Re: SwiftUI Defaults Considered Harmful

#129

Post by 013a »

kllrnohj wrote: post #125
013a wrote: post #96

Earlier quoted context omitted.

We did use to do things generically, but more-or-less the wrong kind of generic. Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc. Of course, devices got better. That set grew to ldpi, mdpi, hdpi, xhdpi, xxhpdi, and xxxhdpi. There's also tvdpi for televisions. It was supposed to be generic. It becam…

> Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc. This example doesn't really work. Those buckets have always been primarily for image asset selection, not UI declaration/layout. It's comparable to the 1x, 2x, 3x that exists in iOS land. Nothing has ever actually replaced those. In any UI toolkit.…

Yeah, that was a misprint on my part; I should have referred to them as density classifiers, which is what they are. My brain got jumbled because my broader point came later on, in how there was a time years ago when many apps were elying on them as a signal for screen size, to the point where I saw apps place layout files in a specific mdpi or xxhdpi folder.

Of course, today, I'm sure the Android landscape is more mature and different; I have less context about the thinking around a modern android app today.

Re: SwiftUI Defaults Considered Harmful

#130

Post by jmull »

dmitriid wrote: post #126
jmull wrote: post #108

Earlier quoted context omitted.

He's suggesting he ought to be able to use imperative Swift control flow constructs in the declarative SwiftUI DSL. I suppose I can't really know exactly what his confusion is, but that just doesn't make sense.

It does make sense. Because SwiftUI creates special constructs for regular language features (if, foreach) despite those features, you know, being available in the language.

It doesn’t make sense because SwiftUI is a declarative language. I understand the confusion, since it uses Swift’s DSL feature and is tightly integrated with Swift, but it is distinct and has it’s own design that isn’t directly compatible with Swift’s imperative control flow constructs.

Now, you can argue that Apple should have created a new imperative Swift-integrated UI framework, and if they had, it would be a good criticism if all the normal Swift control-flow mechanisms weren’t available natively. But the author and you aren’t objecting to SwiftUI’s declarative nature.

BTW, If you manage to map all the kinds of loops, breaks, etc, into SwiftUI it isn’t declarative anymore. You’ve managed to go back from describing the UI in terms of “what” (declarative) to “how” (imperative).

Since the author expresses approval of the declarative nature of SwiftUI and complains about it, I know he’s confused.

Post reply on HN