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

281–290 of 394 posts

Re: SwiftUI

#281

Post by kartickv »

mmargerum wrote: post #260
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.

More than just drawing. They have to reimplement all of the behaviors of the built in controls. I'm sure google is up to the task, but my experience has been there's always things missing and and lag behind native .

> there's always things missing and and lag behind native

Flutter specifically or cross-platform UI frameworks in general?

I don't mind it being different, but does the app feel unpolished?

Re: SwiftUI

#282

Post by astrange »

dimmke wrote: post #91
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!

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.

Most good ideas are old school. Data is more powerful than code because it can be analyzed in more ways - for instance, you can extract all the UI and text from an app, localize and re-insert it, then verify the UI won't break, all without having to execute the app.

If it's all in code you may not be able to get to some of the views or even know it's there. This is called the rule of least power - an example of getting it wrong is C++ iostreams.

Of course I'm sure SwiftUI has solved this.

Re: SwiftUI

#283

Post by saagarjha »

laszlokorte wrote: post #203
saagarjha wrote: post #131

Earlier quoted context omitted.

Those might be functions that alter context of the closure rather than being returned. Or it might be some Swift compiler magic?

So far I found out it's implemented via parameter attribute [1] [1]: https://developer.apple.com/documentation/swiftui/viewbuilde...

Ouch, that’s pretty awful…

Re: SwiftUI

#284

Post by saagarjha »

skohan wrote: post #167
saagarjha wrote: post #131

Earlier quoted context omitted.

Those might be functions that alter context of the closure rather than being returned. Or it might be some Swift compiler magic?

They look like initializers. Functions are lower-case by convention in Swift.

That is convention, but there’s no need to follow it ;)

Re: SwiftUI

#285

Post by astrange »

vedantroy wrote: post #237

This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Then you would get truly native, cross-platform development. Now, the probability this would ever work…

All meta-platforms are themselves platforms; meta-ness is in the implementation. So you could always do this no matter what you started from, but it's not actually a good idea.

https://xkcd.com/927/

Re: SwiftUI

#286

Post by travisgriggs »

divanvisagie wrote: post #92
diffset wrote: post #61

Earlier quoted context omitted.

Where does this leave Storyboards? I can't see complex UI being built in SwiftUI

People are using storyboards for complex UI? I was under the impression that people used the more manual processes with larger teams.

I do a mix. The "program by painting" is great for some things and sucks for other things. Unfortunately, programming UIs entirely by text is terse for some things and incredibly laborious/tedious/boilerplate for others (e.g. doing autolayout in code sucks).

So I end up doing both. The problem (and I've seen this for many years with other similar systems), is that you have to become relatively comfortable with both approaches, so you can make informed decisions about when to flip back and forth. When can I do this with IB even though it's a teensy hacky vs when should I just subclass UIView and take over layoutSubviews and friends?

That's been my experience at least. YMMV.

Re: SwiftUI

#287

Post by Kendos-Kenlen »

trevor-e wrote: post #86
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!

Looks very similar to Anko (a Kotlin Android UI DSL). Awesome work, can't wait to try it out.

It is. And I think SwiftUI will only push people toward Anko as this kind of libraries/tools will become popular. Also, some concurrence with make both tools even better. That's great news!

Re: SwiftUI

#288

Post by kartickv »

thegayngler wrote: post #230
thegayngler wrote: post #158

Thank you so much for this. I was learning iOS again for the fourth time. This time is different. I learned about programmatic UI from Brian LBTA guy which has been so much easier than IB. Now this update just makes my learning iOS a whole lot easier for me. I'm so thrilled. Thank you thank you thank you Apple!!!!!!!!

Why am I being downvoted simply for being happy about this update and that it brings down the learning curve for other engineers?

Unfortunately, many geek forums accept cynicism, negativity, sarcasm and snark, and downvote a happy post, usually with some excuse like "doesn't contribute to the discussion".

Re: SwiftUI

#289

Post by fphilipe »

gwright wrote: post #251
oakesm9 wrote: post #233

Earlier quoted context omitted.

If you mean and official declarative UI library then Google released one of those at Google IO this year: https://developer.android.com/jetpack/compose

I am very interested in multi-platform Kotlin. I'm not sure how far it will get but on the surface I think it is more likely for Kotlin to work on iOS than Swift on Android. Still learning about compose.

> it is more likely for Kotlin to work on iOS than Swift on Android.

Who knows... With Chris Lattner at Google and Google adopting Swift for TensorFlow, I could well imagine Swift eventually working on Android (or something newer).

Re: SwiftUI

#290

Post by chipotle_coyote »

thought_alarm wrote: post #94

I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC. The future of MacOS development is not Marzipan and never was. The future is SwiftUI.

The future of macOS development may be SwiftUI, but that's also the future of iOS, iPadOS, watchOS, and tvOS development.

But I think you're right. Catalyst (née Marzipan) is being pitched by Apple as a brilliant way to get a head start on porting iPad apps to the Mac, and should become the best way to write an app that you want both an iPad and Mac version of. But "Mac apps as we know them are dead" always struck me as histrionic, and today's presentation doesn't make me think that any less.

Post reply on HN