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

371–380 of 394 posts

Re: SwiftUI

#371

Post by JannThomas »

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…

So I've been working with SwiftUI for the past day and I am completely blank on how one would implement a collection view, like one with multiple rows. I did succeed to do it myself with a VStack and multiple HStacks, inside which I basically put the cells. Did they show this in the demo or was it a one-dimensional collection view?

Re: SwiftUI

#372

Post by RodoBobJon »

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…

SwiftUI has state. The idea is that all layout code is defined as a pure function of the state. Basically you can annotate properties with `@State` and each time one of those properties is updated, your view `body` function is re-run to produce an updated view.

SwiftUI tries to do clever stuff under the hood to only update the portions of the view hierarchy affected by the state change for performance.

Re: SwiftUI

#373

Post by dep_b »

eugeniub wrote: post #207
dep_b wrote: post #153

Earlier quoted context omitted.

One thing that Google does right with Android is back porting to older versions.

I'm having a hard time figuring out how this statement can be even remotely accurate.

> I'm having a hard time figuring out how this statement can be even remotely accurate.

I'm not even an Android developer and I already know that tons of Android libraries get back ported to older Android versions. They have to. Nobody runs the latest Android.

It's a bit shocking to get downvoted for a statement that's undeniably true.

Re: SwiftUI

#374

Post by dep_b »

saagarjha wrote: post #157
dep_b wrote: post #153

Earlier quoted context omitted.

One thing that Google does right with Android is back porting to older versions.

Of course, that’s because most manufacturers don’t push updates to their devices and many users are using versions from years ago.

True. But supporting iOS 12 would mean I could start working on SwiftUI apps today.

Re: SwiftUI

#375

Post by RodoBobJon »

mmargerum wrote: post #140
sz4kerto wrote: post #3

To me this looks very similar to what Google is doing with Flutter.

Flutter doesn't use native controls . It draws everything. Just pointing out that difference.

FWIW, the Apple developers discussing SwiftUI on Twitter are careful to point out that SwiftUI is not designed to be a wrapper around UIKit. Much of the implementation currently uses UIKit under the hood, but that's an implementation detail that is subject to change and there are already significant parts of SwiftUI that don't use it.

It seems as though they are viewing SwiftUI as a successor to UIKit/AppKit on all their platforms, not just a higher level wrapper.

Re: SwiftUI

#377

Post by vor_ »

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.

The idea behind Interface Builder is that it writes the class instances and their properties using NSCoding, and they're decoded at runtime and assigned to your IBOutlets just as if you had initialized them in code, set their properties, and assigned them to instance variables yourself. XIBs were introduced with OS X Leopard as a text-based way to store the files in source control, but they're still compiled into binary NIBs when the project is built. You're not supposed to hand-edit the XML.

Re: SwiftUI

#378

Post by myko »

antfarm wrote: post #299
myko wrote: post #268

Earlier quoted context omitted.

Do you develop Android apps? Google also announced a declarative UI framework. It's in the early stages and is open source. Android is on 9.x but that framework will run on much older versions of Android. Meanwhile iOS 12 might be on 85% of iOS devices but it wont ever see SwiftUI.

It will not be on 85% of iOS devices once iOS 13 is available.

Sure, but my company (and I assume most) will maintain support for at least the last two major versions of iOS. We wont be able to be minimum iOS 13 until ~September 2020 at the earliest, probably not until early 2021.

I understand why, I just wish they could release this open source like Jetpack Compose. Would've been a great way to introduce SPM to Xcode and iOS as well.

Re: SwiftUI

#379

Post by jupp0r »

nexuist wrote: post #259
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…

"However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing" Honestly, this is something I've been struggling with coming to terms to for a while. Really, what mobile app isn't just a CRUD thing? Literally every 3rd party app I can think of on my phone talks to some REST service in some way. Even the video games, photo editors, notes apps, etc. They all use the cloud…

I’m working on a realtime video conferencing service. Lots of long running connections with state updated by streamed events. React works pretty well for this use case imho. Not a lot of CRUD there.

Re: SwiftUI

#380

Post by yoz-y »

myko wrote: post #366
yoz-y wrote: post #298

Earlier quoted context omitted.

Vast majority of the people with iOS12 will update. Also, at least on the announcement page, there seems to be no mention of iOS13 required for running apps using SwiftUI. Up until Swift 5 the whole runtime library needed to be shipped with the app and it is quite possible that a SwiftUI library could be shipped and run on iOS12. Edit: On Apple developer forums I've read that the library is annotated with iOS13 requi…

The vast majority of folks will update right away. Not enough to convince my stakeholders that we don't need to support at least one major version back. I'll probably fight that harder this year than in previous years - SwiftUI looks incredible and any AutoLayout code already feels like legacy.

Yeah, I agree that Apple should have added at least one version worth of backwards compatibility if they want to see quick adoption. I suppose one could hide the whole view in defines and lug two implementations but that is not much better than waiting for one year.
Post reply on HN