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

161–170 of 394 posts

Re: SwiftUI

#161

Post by joshjhargreaves »

wtetzner wrote: post #82
untog wrote: post #26

I'd be curious to know how many React Native devs work on cross-platform apps. In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flu…

> In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. But applications written in React Native aren't cross platform, are they? You have different components depending on the platform. My understanding is that they claimed you wouldn't have to learn a different framework when switching to a new platform, not that your apps would be portable.

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. Sometimes you may want to have different behavior per platfrom and for that you can use the Platform API (provided by React Native) to switch for each platform. This would allow you to do things like change the styling on each platform or the native components you use.

React Native makes it pretty easy to expose native components to JavaScript. It is also up to the native component author if they want to create a common API for all platforms that they support. In the case of Views & styling it makes a lot of sense to have the same API on iOS and Android, but sometimes they are some platform features that are only available on one platform.

Wile Swift Layout is not cross-platform, it may soon be and I think it does a lot for promoting declarative UI & maybe they did take some inspiration from React!

View docs: https://facebook.github.io/react-native/docs/view.html Styling: https://facebook.github.io/react-native/docs/style Layout: https://facebook.github.io/react-native/docs/flexbox

Re: SwiftUI

#162

Post by dmitriid »

thought_alarm wrote: post #94

I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC. The future of MacOS development is not Marzipan and never was. The future is SwiftUI.

"A rose by any other name would smell as Marzipan". Even if it's called SwiftUI and not Marzipan, it still has all the same future problems as when it was called Marzipan [1]

[1] https://blog.iconfactory.com/2019/05/what-to-expect-from-mar...

Re: SwiftUI

#164

Post by ng12 »

_bxg1 wrote: post #130
ng12 wrote: post #109

Earlier quoted context omitted.

I think it's a closer analogue to React.useState.

useState is for cobbling together state onto what's supposed to be a pure-function. SwiftUI, like MobX (in its normal usage), is class-based and keeps state in a class member.

What's the difference between a class and a function with local state?

(Semantics aside, either way this behavior is implemented in React via useState or setState, MobX has nothing to do with it)

Re: SwiftUI

#165

Post by grblovrflowerrr »

wtetzner wrote: post #82
untog wrote: post #26

I'd be curious to know how many React Native devs work on cross-platform apps. In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flu…

> In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. But applications written in React Native aren't cross platform, are they? You have different components depending on the platform. My understanding is that they claimed you wouldn't have to learn a different framework when switching to a new platform, not that your apps would be portable.

They are. If you make a react native project using the official boilerplate generator, the resulting project will be able to run on both Android and iOS out of the box, with no modifications. It's true that you might need to use native APIs and components for specific features, but the everyday UI building blocks of RN are cross platform. These are(in my mind): the flexbox layout engine, styleable box/image/text components, animation system, and a touch and gesture interaction system. In addition many of the other parts are cross platform too: geolocation, device dimensions, activity indicators, alerts etc.

Even some of the built-in components are platform specific though, such as the segmented control for iOS and view pager for Android. But the nice thing is you don't need to create a separate project to use these, you can just chose the appropriate one at runtime based on the platform.

Re: SwiftUI

#166

Post by zapzupnz »

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 combine SwiftUI with Project Catalyst, and I'm really hoping to see plenty of high-quality cross-platform apps that don't have a whole instance of Chrome underlying them.

Re: SwiftUI

#167

Post by skohan »

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?

They look like initializers. Functions are lower-case by convention in Swift.

Re: SwiftUI

#168

Post by jamanon »

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!

Can I use that in an existing app?

Re: SwiftUI

#169

Post by tekstar »

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?

Post reply on HN