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

201–210 of 394 posts

Re: SwiftUI

#201

Post by pjmlp »

HillaryBriss wrote: post #191
pjmlp wrote: post #19

Earlier quoted context omitted.

Jetpack Composer you mean. I bet by next IO, Flutter will get replaced by it, specially after the #KotlinEverywhere announcement and Kotlin/Native effort for iOS.

It looks like Jetpack Compose is not really done yet. It's pre-alpha and the Jetpack Compose doc page says don't use it for production. https://developer.android.com/jetpack/compose/ I may be missing something, but SwiftUI seems to be pretty much ready to go today.

You are missing the fact that Android team doesn't want to have anything to do with Dart, and started a Kotlin everywhere initiative, including iOS via Kotlin/Native.

Re: SwiftUI

#202

Post by skohan »

ardit33 wrote: post #179
Redoubts wrote: post #52

var body: some View { Wait, what? When was `some` a keyword?

I am still scratching my head why the 'some' keyword is needed/required for opaque types. Eg. SquareButton and RoundButton are implementations of the Button (protocol). You want to create a function that returns the button, but you don't want to specify to the user exactly what type of button is it (as it doesn't matter). Your function could just declare the top level protocol as the return type without needed to spe…

The difference is subtle but it's there.

The "some" keyword indicates that the function returns a specific type, even if that type isn't known to the caller.

One place where this is meaningful is if you have to use the result of that function in a generic function. For instance if my functions are defined like this:

    func createPlayButton() -> Button { ... }

    func doSomething(_ button: T) { ... }
And I try to call this:

    doSomething(createPlayButton())
I will get an error, because the protocol Button does not conform to itself. However If I use opaque types:

    func createPlayButton() -> some Button { ... }
this works just fine because the compiler is able to determine the concrete type returned by `createPlayButton`

Re: SwiftUI

#203

Post by laszlokorte »

saagarjha wrote: post #131
laszlokorte wrote: post #128

Earlier quoted context omitted.

Yeah but the example code looks like multiple expressions?

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...

Re: SwiftUI

#204

Post by AprilArcus »

grey-area wrote: post #136
jaegerpicker wrote: post #100

Earlier quoted context omitted.

This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI.

This must be the .. fifth entirely new UI framework from Apple? This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI. They didn't say anything about iOS. There have been lots of UI frameworks from Apple, some abandoned before they were even finished: QuickDraw, Quickdraw GX, HIToolbox, AppKit, Cocoa Touch/UIKit, Playgrounds/IB, SwiftUI The constantly changing frameworks and languages…

QuickDraw and Quickdraw GX aren't UI frameworks (like PowerPlant, AppKit or UIKit), and they aren't a widget library (like HIToolbox). They're much more lower-level than that; drawing libraries on the level of Quartz, Cairo, Skia, or GDI.

Re: SwiftUI

#205

Post by gwright »

mooman219 wrote: post #79
vijaybritto wrote: post #40

Earlier quoted context omitted.

This is incredibly awesome! Did you get inspired by the web or by new frameworks like flutter?

This looks very similar to Flutter, I wouldn't be surprised if they took some ideas from that which is all well and good; UI construction needs a facelift.

That is exactly what I said when I saw the code on the screen. Now if they released a development environment for Android also.... (wishful thinking)

Re: SwiftUI

#206

Post by robertAngst »

zapzupnz wrote: post #166

I'm sure SwiftUI has been in development for a long time, but it seems to me to be Apple's response to frameworks like React Native and Electron. We get a simple way to make UIs for multiple platforms, we get a nice batteries-included language, and Swift 5.1's dynamic method offers a similar functionality to hot reloading. Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) but combin…

>Of course, it can't answer everybody's needs (no Windows, Linux, or Android support)

I don't understand how my fellow developers could ever tolerate Apple doing this.

This goes one way, and its been like this for decades.

Re: SwiftUI

#207

Post by eugeniub »

dep_b wrote: post #153
eugeniub wrote: post #137

Earlier quoted context omitted.

Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.[1] Last year, iOS 12 didn't drop support for any devices. The iPhone 6 is a very popular device, and was still sold by Apple less than two years ago. [1]: https://iosref.com/ios/

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.

Re: SwiftUI

#208

Post by lucasverra »

vijaybritto wrote: post #97
mooman219 wrote: post #79

Earlier quoted context omitted.

This looks very similar to Flutter, I wouldn't be surprised if they took some ideas from that which is all well and good; UI construction needs a facelift.

I think if flutter can provide this kind of editor support and experience it would be indispensable for me! Also I'm pretty sure the web would emulate this one pretty soon!

swift ui to react !

Re: SwiftUI

#209

Post by julius_set »

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…

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

Re: SwiftUI

#210

Post by EdwXD »

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.

yes, my team have been using Storyboard/xib for 99% Auto Layout declaration, PaintCode for rendering custom components (which can be shown directly inside IB), RxSwift/RxCocoa for MVVM
Post reply on HN