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

311–320 of 394 posts

Re: SwiftUI

#311

Post by grey-area »

pwinnski wrote: post #176
grey-area wrote: post #136

Earlier quoted context omitted.

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 debuted 35 years ago. QuickDraw GX was 24 years ago. Etc. You're saying that MacOS has been around a long time, which is true.

:) Fair point.

Re: SwiftUI

#312

Post by jamil7 »

eugeniub wrote: post #137
fphilipe wrote: post #7

Personally, as an iOS developer, this is by far the biggest announcement. Haven’t had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising. The only downside is that we’ll have to wait one or two years before we can use it if older iOS versions still need to be supported. Let’s hope for extra quick adoption of iOS 1…

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/

Does this include 6 Plus? I grabbed one second hand recently and it's been working great for an iOS side project, would be sad if I couldn't use any of this.

Re: SwiftUI

#313

Post by consp »

npunt wrote: post #235
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/

According to Mixpanel, the 5S / 6 / 6 Plus together account for a bit less than 10% of iOS devices they see. So it's not as big of a drop as one might expect. https://mixpanel.com/trends/#report/iphone_models

That is way more than most companies will part with. If support drops substantially below 1% we can talk again.

Re: SwiftUI

#315

Post by diroussel »

jiyinyiyong wrote: post #294
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.

You could call this hypothetical tool Interface Builder.

Re: SwiftUI

#316

Post by mythz »

pjmlp wrote: post #307
mythz wrote: post #238

Earlier quoted context omitted.

Flutter's not a PR campaign for Dart, they're a separate project that chose Dart based on its technical capabilities [1]. Given Flutter enables the nicest native x-plat dev experience today I'd say it has a very bright future, which they've also recently announced Flutter for Desktop and Embedded devices. Jetpack compose is years away from the same kind of x-plat support that Flutter's providing for Mobile, Web, Desk…

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 "technical capabilities".

Am I meant to be impressed by this list of languages? I'm not. Are the number of languages meant to give your inexperienced opinion on Flutter's development environment some credence or is this washy strawman meant to downplay anyone else's opinion who wasn't a developer in the 90's when these languages were more relevant?

What matters is what's relevant now and Flutter lets you build modern x-plat Mobile, Web, Desktop and Embedded Apps with productive Live Hot Reload environment that's both fast at development and runtime which can be run in a JIT VM, as AOT compiled or transpiled to tree-shaken JS. Which of these above languages provides a more productive and "technically impressive" environment to develop iOS/Android, Web and Embedded Apps than Dart/Flutter?

> Flutter is a way to rescue Dart, plain and simple.

Adding "plain and simple" to an baseless opinion doesn't re-enforce it, including links that backs up this wild speculation will. What information have you used to be able present this opinion as fact so staunchly? Do you really believe Google invented and funded the Flutter project out of thin air to give Dart a popularity boost?

> And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.

How can Android have more political power for Fuchsia than Dart which is what most of its UI is written in? You can also develop Flutter Apps on Chrome OS so that's no different. Chrome OS is still primarily a Web OS, allowing running Android Apps doesn't make it an OS for running Android Apps and devs aren't going to be lining up to develop Chrome OS Apps using Android.

Flutter's strength's is that you can develop x-plat App's that looks, behaves and runs natively on all its supported platforms - feel free to wait until Kotlin reaches the same maturity on iOS before declaring it a Flutter killer. Kotlin still suffers from Android's complicated and fragile tooling and from what I've seen with JetPack compose it's highly coupled to Android - it's going to take a long time before they'll let you build iOS/Android Apps from a single code base.

Re: SwiftUI

#317

Post by pzo »

thomasjames wrote: post #31

Interesting move we see from the big players to more declarative UI toolkits. First Flutter, now this.

You have to give credit to react time which seems that started this paradigm of declarative and reactive ui frameworks. After that you got react native, flutter, jetpack compose and now swift ui. As for declarative (but not reactive) ui prior art is also Qt qml.

Re: SwiftUI

#318

Post by laszlokorte »

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

More details in the proposal [1]:

> the basic idea is that we take the "ignored" expression results of a block of statements — including in nested positions like the bodies of if and switch statements — and build them into a single result value that becomes the return value of the current function.

[1]: https://forums.swift.org/t/pitch-function-builders/25167

Re: SwiftUI

#319

Post by pzo »

checker659 wrote: post #56

One more blow to the head for objective-c. Wonder if this the final nail in the coffin.

Final blow at least for me will be at least some minimal interop with c++ (instead of just c) and sort of reflection mechanism.

Re: SwiftUI

#320

Post by Quenz »

zapzupnz wrote: post #221
robertAngst wrote: post #206

Earlier quoted context omitted.

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

Because not all of your "fellow developers" have the same priorities as you. For a lot of developers, targeting just the Apple platforms is still a worthwhile investment in itself: Apple's customers tend to pay higher prices for quality Mac software — yes, outside the Mac App Store, too — and they will very often be happy to pay for the accompanying iOS app if it's worth doing so. There have been Apple-only developme…

There sure are a lot of developers only interested in developing for Apple platforms. But wouldn't it be beneficial for Apple to extend the framework outside their ecosystem? I doubt the reason they haven't is to limit expending resources.
Post reply on HN