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

111–120 of 135 posts

Re: SwiftUI Defaults Considered Harmful

#111

Post by jamil7 »

uwuhn wrote: post #94
jamil7 wrote: post #84

Earlier quoted context omitted.

SwiftUI is raising the abstraction layer and aiming to provide something much more productive than what UIKit currently offers. You've framed your comment as if web developers are cargo-culters who only know how to use React. The web has already experimented with classic MVC approaches (backbone etc.) and moved beyond it. Android's Compose is taking a similar approach, as is Flutter which as far as I can tell is not…

I don't believe they'll ban it. I do believe they'll increase friction to the point that it becomes a huge pain to use either for anything but prototyping.

I can't see really why they care that much how the app is written, if it adhears to the app store guidelines and makes them money then I doubt they're that interested in banning it or increasing friction. Nearly all the current top selling iOS games are likely written in Unity and I can't see them banning that.

Re: SwiftUI Defaults Considered Harmful

#112

Post by chiefsucker »

5cott0 wrote: post #52
madeofpalk wrote: post #30

Reading through the syntax changes they made makes me really appreciate the decisions made around JSX and how that works, syntactically. It's just javascript , and none of these weird constructs need to be added into some DSL to support it. There's the reasonably minimal html-ish syntax, then "escape to javascript" to add in conditionals or loops or whatever. I wonder if there was (or still is) a way to do something…

.nib & .storyboard files are XML based so one could conceivably write a dsl to represent interface builder xml in swift if one doesn't already exist. SwiftUI is a definite move away from interface builder.

Those two statements contradict somehow.

Why wouldn’t Apple be able to switch XML with a Swift DSL and keep the Interface Builder UI intact after most of the biggest SwiftUI issues get fixed?

Re: SwiftUI Defaults Considered Harmful

#113

Post by chiefsucker »

jamil7 wrote: post #111
uwuhn wrote: post #94

Earlier quoted context omitted.

I don't believe they'll ban it. I do believe they'll increase friction to the point that it becomes a huge pain to use either for anything but prototyping.

I can't see really why they care that much how the app is written, if it adhears to the app store guidelines and makes them money then I doubt they're that interested in banning it or increasing friction. Nearly all the current top selling iOS games are likely written in Unity and I can't see them banning that.

Platform coherence, but also look & feel come to my mind.

While the guidelines are what the word says, vague guidelines with a lot of room for interpretation, they don’t necessarily dictate any details. When you look at it from a more technical point of view, it’s harder to do something nonconforming with Apple’s frameworks than with 3rd party alternatives.

Games are a different thing. They are more like their own operating system within iOS and usually have their own quirks (to make them playful).

Re: SwiftUI Defaults Considered Harmful

#114

Post by rubyn00bie »

I think everything after the first gripe is a fair point, but I don't get what the problem is with the first code chunks... it seems like the author is saying "this is weird to me, and I don't like that," but I have no idea how else it'd work properly.

For example, explicitly defining out function arguments is exactly what Scala does for function, check out this bad mofo, defining a function with 22 arguments (that I fell in love with years ago): https://www.scala-lang.org/api/current/scala/Function22.html

Why'd I fall in love with it? Because it makes sense, that's how it should work right? I don't see how defining out 10 items explicitly; so, that each can have it's own type, is a problem. It's pretty damn nice they did it out to ten arguments, if you want more, extend the object... /shrug

If you used a list instead, e.g. `T[A]` you'd take a hot-fat erasure-shit on the type information of each item in the list (or at least you would last time I used Swift extensively)... this way you keep that type information around.

P.S. To be honest, explicitly defining things out like that can give you HUGE wins in languages like Swift because you give the compiler so much more information. It just doesn't usually pop onto most folks radar because it looks obtuse... with most modern code editors though it's easy enough to write in a couple minutes, if there's no macro system.

Re: SwiftUI Defaults Considered Harmful

#115

Post by SlowRobotAhead »

013a wrote: post #98
SlowRobotAhead wrote: post #28

Earlier quoted context omitted.

The point isn’t that adaptative spacing does a good job most of the time, it’s that it’s doing things it isn’t telling you about in code and you “just need to know” for when it isn’t doing a good job. Think about having to remember UI padding voodoo the couple days after you back from a vacation. The UIkit shouldn’t try and hide language normal commas, it shouldn’t try and imply “smart” or “magic” padding.

Similarly, We've all seen incomprehensible ten-thousand line CSS styles sheets, with layers of inheritance, where you're forced to grep through to find that one line on some ancestral class that controls the left padding for every h1 on the site... except this specific one, which I guess is using !important on its own class? Damn it. So, what'll it be? We're talking about inherent complexity. Should it be application…

>"Oh, yeah, I need padding on that, how much? 4 pixels I guess. Is that standard? Wait, no, i think we moved to 8px recently. Or, wait did we move this to 'em'?"

I'm not sure how the magic/JustUsuallyWorks/ solution fixes this issue. If the argument is people need to remember things, and SwiftUI takes that away and just puts in what an algorithm thinks is right, that's probably going to be pretty generic design for the final product.

Re: SwiftUI Defaults Considered Harmful

#116

Post by ogre_codes »

erikrothoff wrote: post #105
ogre_codes wrote: post #76

Earlier quoted context omitted.

> ... after having done a lot of React development recently ... All this prompted me to finally give react-native a try. In under 15 minutes I had a working example. The fact that you, a React developer with lots of experience with React were able to come up to speed vastly quicker on React Native shouldn't be surprising, that's a feature of the platform. You are the exact sort of person React Native was designed to…

Sorry if it wasn't clear enough. I'm by no means a React-developer with lots of React experience. I'd say I have more iOS-development experience than React. The app I wanted to port is already fully written in Swift. I've written and launched a couple of apps in Swift over the years, and also a couple of apps in Objective-c.

Fair enough.

I think time is the big decider here. Swift is new and given Apple's relatively slow update cycle (annually versus quarterly or more often for open source projects), it'll be a few years before SwiftUI really matures and (hopefully) a community builds up around it.

This year's Apple Dev Conference (If it happens) should push things forward and hopefully increase the quality and quantity of documentation at the least.

Re: SwiftUI Defaults Considered Harmful

#117

Post by AgentME »

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…

>Its not like I'm saying "if screen width is above 750px, render X" (cough css).

CSS "px" units are only raw pixels on 96dpi displays. It's normalized with respect to the dpi. On higher-dpi displays, CSS "px" can refer to multiple pixels. So controlling layout based on the screen's width in "px" is fine; it won't break when someone switches to a super high dpi device.

Re: SwiftUI Defaults Considered Harmful

#118

Post by myko »

saagarjha wrote: post #44
briandear wrote: post #37

Earlier quoted context omitted.

How many people are using iOS 9?

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.

Re: SwiftUI Defaults Considered Harmful

#119

Post by chipotle_coyote »

jamil7 wrote: post #81
kenshi wrote: post #73

Earlier quoted context omitted.

I suspect Apple knows the developer experience for Swift is terrible (even if the Apple developer community at large is in mass denial about this). The number 2 item on Swift Core Teams goals for Swift 6 is "Create a fantastic development experience". See: https://forums.swift.org/t/on-the-road-to-swift-6/32862 Whether anyone at Apple cares about documentation any more is another matter. A really sad state of affairs…

I don't know, maybe some of the die hards are in denial. I really enjoy the language and the platforms but I'd readily admit it's pretty far behind in terms of DX. I think at this point Apple is going to have to make this a really big priority if they want to remain relevant and it's going to take a lot of effort on their part.

While I certainly can't speak for all diehards, I hear a lot of complaints about the state of Apple's documentation from long-time developers these days. (In my experience, the true Apple diehards are often very critical of the company, but they tend to have specific trenchant critiques.)
Post reply on HN