Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

101–110 of 343 posts

Re: SwiftUI After 7 Years

#101

Post by blltprfmnk »

kccqzy wrote: post #100
blltprfmnk wrote: post #77

Earlier quoted context omitted.

There were a lot of people actively complaining about ObjC in the lead-up to the unveiling of Swift. In fact I recall one prominent blogger in the iOS community begging Apple just a few months earlier to consider replacing it. Unfortunately although Swift seemed promising at first, by the time Swift 3 rolled around a lot of people were actively frustrated and moved on from iOS development. Having actual experienced h…

Are you talking about the unveiling of Swift or SwiftUI? My recollection was that some people hated ObjC and wanted a more modern language. Apple gave them Swift. But I don’t recall people hating AppKit (maybe I wasn’t remembering correctly) and SwiftUI was basically Apple following the hipster trend.

Just referring to Swift.

Agree that SwiftUI was just jumping on a bandwagon and would say that the design of SwiftUI clearly strains the poor language design choices in Swift.

Re: SwiftUI After 7 Years

#102

Post by happytoexplain »

emehex wrote: post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

I have always treated state as the source of truth in UIKit. Every view gets an equatable state struct, and mutating it triggers an idempotent view update. Self-mutating views (e.g. inputs) back-propagate their state up the view hierarchy.

SwiftUI/React/etc don't introduce that pattern, they simply enforce it (and add efficiencies).

If a developer isn't familiar with the pattern, it's not because they are a UIKit dev, it's because they are inexperienced.

Re: SwiftUI After 7 Years

#103

Post by happytoexplain »

frizlab wrote: post #90
emehex wrote: post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

More or less the same happened with ObjC vs. Swift when it came out, I think.

I don't know, in my circles Swift was welcomed like a long-awaited friend. We loved ObjC, but none of the advantages ObjC has over Swift are relevant to app dev. Conversely, everybody recognized the beauty of most early Swift features, notably Optionals.

Re: SwiftUI After 7 Years

#104

Post by dosisking »

rayiner wrote: post #3

The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is…

> Could Apple build MacOS X and Cocoa today if they didn't already exist?

Apple got rid of all the NeXT people long ago, with Tim Cook stabbing Scott Forstall in the back, so the answer is No.

Re: SwiftUI After 7 Years

#109

Post by LoganDark »

mpweiher wrote: post #80
kodebach wrote: post #59

Earlier quoted context omitted.

The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly . With imperative UI code it is incredibly easy to forget an edge case in your update logic.

Not if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.

Are you saying the UI always updates its entire self whenever anything changes in the model?

Re: SwiftUI After 7 Years

#110

Post by oefrha »

CharlesW wrote: post #81
emehex wrote: post #55

I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.

> I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is true. SwiftUI became "very good" as of iOS 26 (in part because the performance gap mostly evaporated) and continues to get better in iOS 27. Over and over, I see UIKit developers trying to do things "the UIKit way" in SwiftUI, and they'd rather write TFAs instead of considering that they may need to ski…

Now, if only that code you write for iOS 27 can also work on older versions of iOS, instead of having to maintain legacy code for old versions forever…
Post reply on HN