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

SwiftUI

developer.apple.com

Post reply on HN
Print view View original

331–340 of 394 posts

Re: SwiftUI

#331

Post by pjmlp »

mythz wrote: post #316
pjmlp wrote: post #307

Earlier quoted context omitted.

That after-the-fact reasoning link that gets posted every time someone questions Dart is well known, no need to give it to me. Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities". Flutter is a way to rescue Dart, plain and simple. Yes, Jetpack Compose might be doing its baby steps, but I am betting most developers are…

> no need to give it to me. Think highly of yourself much? But I'll be continuing to provide links as I see it's relevant and informative, my comments are not just for your benefit, readers can make their own mind whose opinions are more informed - "no need" to tell others how to comment. > Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "…

What information have I used?

Besides Dart v1.0, Dartium, Angular Dart when they were still relevant to Chrome and Angular teams, and following up on Flutter?

I usually only criticize stuff that I actually have some level of experience with.

AdWords team rescued Flutter, after Chrome and Angular teams stop caring, which even caused Dart designers like Gilad to leave in disagreement.

I believe that they found out some internal management support that is willing to give them a time frame, of lets say 5 years to prove themselves worthy of such support.

Android has more political power ChromeOS has adopted Android and not the other way around, the two commercial OSes from Google.

While their experimental OS, Fuchsia is now adding support to run ART, while at the same time via Scenic, decoupling themselves from the UI framework.

You want to believe in Dart/Flutter, go for it.

Me, I am betting it will be joining the list of abandoned Google projects in a couple of years.

Re: SwiftUI

#332

Post by [deleted] »

ambivalence wrote: post #327
simonh wrote: post #321

Earlier quoted context omitted.

Yep, if your margins are 20% and you lose 10% of your user base and revenue, you just lost half your profit.

I must be missing something here. Assuming on a napkin that all users roughly generate the same amount of revenue, losing 10% of them will lose you 10% of your profit, no? If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.

[deleted]

Re: SwiftUI

#333

Post by saagarjha »

ambivalence wrote: post #327
simonh wrote: post #321

Earlier quoted context omitted.

Yep, if your margins are 20% and you lose 10% of your user base and revenue, you just lost half your profit.

I must be missing something here. Assuming on a napkin that all users roughly generate the same amount of revenue, losing 10% of them will lose you 10% of your profit, no? If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.

It depends on how you're calculating it: if you have fixed costs, then yes, your profit drops 50%; if your costs scale with number of users then you go down 10%.

Re: SwiftUI

#334

Post by saagarjha »

pier25 wrote: post #291
HillaryBriss wrote: post #188

Earlier quoted context omitted.

yes, they're drawn too. but, i think what the above comment is pointing out is that Flutter itself does the drawing, instead of delegating the drawing to iOS or Android native widgets.

Actually no, Flutter doesn’t do the drawing. It’s done by Skia, much like Cocoa native controls are drawn by Quartz. There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.

> There isn’t much of a difference between Flutter controls and native controls

Except that they behave quite differently…

Re: SwiftUI

#335

Post by Grustaf »

pvinis wrote: post #328
archagon wrote: post #242

Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative co…

If you combine a declarative UI like SwiftUI and a reactive logic like RxSwift, you can get very far, while keeping things separated and simple. Not only for CRUD apps, but for big complex apps too.

Don’t use it with RxSwift, use it with Swift Combine! https://developer.apple.com/documentation/combine

Re: SwiftUI

#336

Post by aaronbrager »

kartickv wrote: post #280
ng12 wrote: post #109

Earlier quoted context omitted.

I think it's a closer analogue to React.useState.

Does that mean that UI will automatically get updated when the model changes, and you no longer need a mess of dependencies, like "if A changed, update X and Y".

Yes

Re: SwiftUI

#337

Post by aaronbrager »

_bxg1 wrote: post #130
ng12 wrote: post #109

Earlier quoted context omitted.

I think it's a closer analogue to React.useState.

useState is for cobbling together state onto what's supposed to be a pure-function. SwiftUI, like MobX (in its normal usage), is class-based and keeps state in a class member.

SwiftUI is protocol-based, not class-based

Re: SwiftUI

#338

Post by Cthulhu_ »

myko wrote: post #262
julius_set wrote: post #209

Earlier quoted context omitted.

If you find iOS / macOS views cumbersome to write programmatically you should feel fortunate you didn’t have to write Android views programmatically.

True but who does this? The Android framework isn't built to support that reasonably at all, at least not until Jetpack Compose becomes viable.

Wasn't that the default way of doing things in Android? That is, build your ui's in XML?

Re: SwiftUI

#339

Post by bsaul »

vbezhenar wrote: post #30
kylemacomber wrote: post #8

I’m one of the engineers that spearheaded this initiative inside of Apple. I just wanted to thank the HN community—I’ve been reading HN for 10 years now and it’s been formative in my development as a software engineer. If you’re at WWDC stop by the labs and say hi!

IDE support is jaw-dropping. I did not see that kind of integration between text and UI anywhere. Framework code looks like React from the first glance, but IDE integration is game-breaker.

After 10 years of following wwdc: you may want to temper your expectations as to what this will truely feels like once this runs on your machine, on a real-size project.

Apple is famous for making great on-stage demos that collapse once they're faced with the real-world (eg: basically anything related to having a great xcode experience)

Re: SwiftUI

#340

Post by sjwright »

steve1977 wrote: post #305
dimmke wrote: post #91

Earlier quoted context omitted.

I just wanted to say thank you - I'm a web developer who has been learning iOS dev in his spare time and made the decision pretty early on to build my views programmatically. It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically. Also, the code for building UIs programmatically ha…

> It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically. Well you know, Cocoa and its predecessor OPENSTEP were built on the idea of using IB to compose interfaces out of actual objects that then got "freezed" into a file. So, no code at all, that was the idea. Building views prog…

And the IB approach is a nice one, except that its files (whether NIB or XIB) simply don't diff as nice as the equivalent in code. Checking changes into source control is an opaque experience as the diff is an endless vomit of unintelligible mumbo.

What is so astonishing about SwiftUI is that it's simultaneously the most impressive looking visual GUI builder I've ever seen... and the most terse, diff-able syntax I've ever seen. I can't think of anything that has combined these two properties quite so successfully.

Post reply on HN