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

291–300 of 394 posts

Re: SwiftUI

#291

Post by pier25 »

HillaryBriss wrote: post #188
pier25 wrote: post #183

Earlier quoted context omitted.

Native controls aren't drawn too?

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.

Re: SwiftUI

#293

Post by mleonhard »

childintime wrote: post #190

I was waiting for Apple to react to Flutter. It was a threat. They couldn't bluntly forbid Flutter apps. Now it seems this is their answer. Soon you'll be able to compile SwiftUI to Flutter and reach all platforms it reaches. Their play: to get the best experience, you'd still need to buy an iPhone.

Who said anything about compiling SwiftUI to Flutter?

Re: SwiftUI

#294

Post by jiyinyiyong »

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!

If Apple is willing to create a GUI tool for generating the DSL used in SwiftUI, it's not far from enabling UI designers to generate UI by themselves. We may need a lower-level representation for the DSL though. I think it's not a problem that we go one step further and make it happen in the next few years.

Re: SwiftUI

#295

Post by protomyth »

adamnemecek wrote: post #275
protomyth wrote: post #249

Earlier quoted context omitted.

Given that Craig Federighi basically said this type of migration only comes around every 20 years, I would imagine Objective-C is dead. I do hope they actually take the time and fix the Swift examples so they are updated. This does hurt. I've been programming Objective-C since NeXTSTEP and love it. Swift is still like Perl for me. Something I will use for programming for money, but not enjoy for one minute. I loved t…

How is swift a javascript clone? Objective c is insanely verbose.

How is swift a javascript clone?

They ditched the selector syntax and went to a Javascript / C++ like syntax. There were so many ways to keep the selector syntax, but they went conformist.

Objective c is insanely verbose.

well, no - Swift's call syntax actually results in the same or more characters:

  somePoint.moveBy(x: 2.0, y: 3.0)

  [somePoint moveByX: 2.0 y: 3.0];

  somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0)

  [somePoint moveByX: 2.0 y: 3.0 z: 4.0];
Swift benefited from some shortening of the method names that can be equally applied to Objective-C. Plus, why the whole split by a left parentheses and comma thing?

Re: SwiftUI

#297

Post by perchard »

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…

"The dirty secret:

We’re all just building CRUD apps."

https://twitter.com/iamdevloper/status/455409190505562112

Re: SwiftUI

#298

Post by yoz-y »

myko wrote: post #268
eugeniub wrote: post #207

Earlier quoted context omitted.

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

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.

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

Re: SwiftUI

#299

Post by antfarm »

myko wrote: post #268
eugeniub wrote: post #207

Earlier quoted context omitted.

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

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.

Re: SwiftUI

#300

Post by skohan »

nicky0 wrote: post #214
skohan wrote: post #202

Earlier quoted context omitted.

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 thi…

Why doesn't a protocol conform to itself?

In many cases it doesn't make sense. For instance, what if your protocol contains a static member?

    protocol P {
        static var x: Int { get }
    }
Here `let x = P.x` doesn't make any sense, because it's only the type implementing the protocol which has that member. However this would be possible:

    func f() -> some P { ... }
    let p = f()
    let x = type(of:p).x
because in this case p has a concrete type, we just don't know what it is.
Post reply on HN