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

221–230 of 394 posts

Re: SwiftUI

#221

Post by zapzupnz »

robertAngst wrote: post #206
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.

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 development houses since the year dot and this won't change just because Apple decided to release a platform to make it a little easier for its developers; they're not beholden to the rest of the world and it's ridiculous to believe so.

Re: SwiftUI

#222

Post by grey-area »

penagwin wrote: post #186
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…

I firmly don't believe they're changing frameworks to "provide platform lockin". Development philosophies change over time, like the other's said, some of those UI frameworks you mentioned are 20+ years old. It does suck that we can't use it on other platforms, and I'm sure they don't want to spend resources on doing so, but there's no way the main motivation is to keep people switching frameworks constantly.

That's certainly not why the programmers involved do it, they do it to improve things, but the effect is platform lockin, which is not at all unwelcome for platform vendors and I suspect is why the companies are quite happy with constant churn in languages and tools. I'm not suggesting that is 'why they do it' just that it is a strong incentive to keep doing it.

If they don't control the language and tools for the platform, they don't control the platform.

Re: SwiftUI

#223

Post by zapzupnz »

binthere wrote: post #217
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…

I wouldn't call anything close to cross-platform if it only works on Apple's products and devices.

You're welcome to your definition, but if you think developing for desktops, notebooks, smartphones, and tablets, with all the differences they encompass is trivial, you're in for a shock.

Even with other cross-platform offerings like Flutter, React, Electron and so on, getting one codebase to work out of the box on just two platforms can be a challenge. On mobile, there tends to be a need to drop down from the cross-platform stuff to something native for performance reasons — Discord does this for its chat buffer on iOS, Facebook does this for practically everything.

So while people take to their ideological high horses, there'll be people out there who can really benefit from being able to develop for Macs, iPhones, iPads, Apple Watches, and Apple TVs with a single, familiar, and easy yet powerful API to provide a glass of ice water in cross-platform hell.

Re: SwiftUI

#224

Post by [deleted] »

ng12 wrote: post #212
_bxg1 wrote: post #171

Earlier quoted context omitted.

MobX takes normal data (usually class properties) and makes it observable, via an annotation. That very much appears to be what the @State annotation in the Swift code is doing, though I don't know for sure. setState is a totally special container for data; while it technically lives in a class member (this.state), it can only be modified via setState. It isn't observable, so much as setState just internally triggers…

@observable/useState/React.Component.state are all conceptually identical, just with varying implementations of the magic. All of them summon an observable value from the void and provide some method of updating said observable. That said, @State seems most identical to useState -- it provides an observed value which you use $/.binding to update. > It's very weird and funky because the whole point of non-class compon…

[deleted]

Re: SwiftUI

#225

Post by 1v1id »

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…

Even if you only develop for iOS at the start, the nice part of RN is the promise of simplified porting. So while the number of people targeting multiple platforms at the start may be low, the number who would consider it "on the roadmap" (or possibly on the roadmap depending on the app's success) is pretty high in my experience.

Re: SwiftUI

#226

Post by weberc2 »

sjroot wrote: post #119
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 was hoping to hear more discussion about performance. At the root of this seems to be a flexbox-esque implementation in Swift. Yoga, one such flexbox implementation written in C, has touted much better performance over UIKit for a while. How do apps built with SwiftUI compare to their UIKit alternatives? How would it compare with some solutions already in the Swift OSS community that utilize flexbox? [Texture]( htt…

Minor bit of pedantry--Yoga is written in C++.

Re: SwiftUI

#227

Post by RantyDave »

chadlavi wrote: post #6

The question the whole web asks now: what does this mean for React Native devs

I think React Native devs still want to be able to deploy to Windows. Unless I'm really missing something here...

Re: SwiftUI

#228

Post by robertAngst »

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…

Given the high cost, high cost options exist on other platforms that are also fantastic.

So if everyone can spend 3,000 dollars and get best in class computing, what are you paying for with Apple?

They have lots of marketing that psychologically makes you feel good?

Re: SwiftUI

#229

Post by zachgray »

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!

not all heroes wear capes

Re: SwiftUI

#230

Post by thegayngler »

thegayngler wrote: post #158

Thank you so much for this. I was learning iOS again for the fourth time. This time is different. I learned about programmatic UI from Brian LBTA guy which has been so much easier than IB. Now this update just makes my learning iOS a whole lot easier for me. I'm so thrilled. Thank you thank you thank you Apple!!!!!!!!

Why am I being downvoted simply for being happy about this update and that it brings down the learning curve for other engineers?
Post reply on HN