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

381–390 of 394 posts

Re: SwiftUI

#381

Post by HillaryBriss »

pier25 wrote: post #291
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.

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.

another noteworthy difference is that the look and feel of a widget is locked down at compile time in a Flutter app.

by contrast, with a native android app, the look and feel of the widget can change on an end user's device when the end user updates android on their particular device.

Re: SwiftUI

#383

Post by dgellow »

zaiste wrote: post #348
dgellow wrote: post #314

Something like this available in C++ would be so great for cross platform applications!

There is Boden (native apps from a single C++17 codebase) https://www.boden.io/

As far as I understand Boden is still a work in progress, far from being ready for prime time.

Re: SwiftUI

#384

Post by madeofpalk »

pier25 wrote: post #291
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.

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.

> There isn’t much of a difference between Flutter controls and native controls

Except they're not actually native controls. They're reimplementations of them. It is a very important distinction.

Re: SwiftUI

#385

Post by Razengan »

pvinis wrote: post #329
joshjhargreaves wrote: post #161

Earlier quoted context omitted.

Applications written in React Native typically are cross-platform; saying that they are not is a pretty large misrepresentation of the framework. At its base React Native provides a common set of native components with the same API on both iOS and Android such as View, Image & Text which can all be styled and laid out through common APIs. These APIs pretty much give you most of what you need to make an entire APP. So…

Maybe we need to coin a new term. React Native is for cross-platform. SwiftUI is for cross-device. Does that work?

Cross-ecosystem vs. cross-platform maybe.

Re: SwiftUI

#386

Post by tewha »

BrandonSmith wrote: post #346
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/

I smell a low-cost iPhone offering late Summer.

Lower than the $0 they're already offering the Xr at? :)

Re: SwiftUI

#387

Post by samskiter »

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!

Now you've really given us a dilemma - switch to Flutter or wait and see if SwiftUI goes open source....

Re: SwiftUI

#388

Post by random001 »

pjmlp wrote: post #331
mythz wrote: post #316

Earlier quoted context omitted.

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

What information have I used? Besides Dart v1.0, Dartium, Angular Dart when they were still relevant to Chrome and Angular teams, and following up on Flutter? I usually only criticize stuff that I actually have some level of experience with. AdWords team rescued Flutter, after Chrome and Angular teams stop caring, which even caused Dart designers like Gilad to leave in disagreement. I believe that they found out some…

I think dart/flutter serves primarily two purposes, as I see it. First the obvious one, Google is trying to get devs used to flutter as when the time comes to switch to Fuchsia/Zircon, it would be relatively a breeze.

Secondly, and the most immediate reason, I think it's a very clever and clear move from Google to lock-in devs into using Google Cloud services like Firebase and Cloud ML services by leveraging Flutter. If you have observed, Microsoft has given a rebirth to their Xamarin developers YouTube channel and have been hosting 'The Xamarin Show', which is, hmm, quite similar to 'The Boring Flutter Development Show'.

Re: SwiftUI

#389

Post by lanjoe9 »

julius_set wrote: post #209
dimmke wrote: post #91

Earlier quoted context omitted.

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.

You can always create a layout XML file and inflate it. It saves tons of time. I can't imagine why you would do thing in code instead of inflating and attaching them.

Honestly, if not for SwiftUI, I find developing interfaces in Android to be infintely faster than either fighting Apple's Interface Builder or building things by code in Swift.

Re: SwiftUI

#390

Post by fontenaut »

tekstar wrote: post #169
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!

Back in 2016 we built layer in Swift with a similar goal at Shopify, called FunctionalTableData. FTD's syntax isn't nearly as nice as SwiftUI, but there's many similarities. https://github.com/Shopify/FunctionalTableData Purely for our own vanity - did Apple engineers take any inspiration from FTD? Or just independently set out to solve the same problems we had?

I saw somewhere that all this started around 2012.
Post reply on HN