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

71–80 of 343 posts

Re: SwiftUI After 7 Years

#71

Post by torginus »

skydhash wrote: post #16
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…

I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs). React works well, because it's only an abstraction over the real DOM. Reac…

Imo the biggest issue with this functional model (at least in React), is that it handles things like virtualization, async, etc. poorly. Which is kinda ironic, because in a true functional language, it'd be feasible to provide 'a world model' - that is act as if the entire state is always available, and let the engine decide when to evaluate pieces of code - without any effort from the part of the programmer.

Unfortunately when complex state transitions, async, and virtualization enters the discussion, the magic of React breaks, and you have to deal with all that, and also deal with how React's engine handles things under the hood.

Re: SwiftUI After 7 Years

#72

Post by palata »

zer0x4d wrote: post #64

SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps. 1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each m…

Apple seems to be loved by users, but hated by developers (and for good reasons). They just seem to not give a shit about the developer experience.

You mention some examples, I have experience with lower-level stuff: terrible. Poorly documented, and actually not really working well.

IMO they should focus on improving the developer experience instead of wasting money on the joke that is Liquid Glass (even users don't like it, right?). But anyway, too late for me: I'm soooo happy that I can develop iOS apps in Kotlin now, and just endure Xcode for building and occasional debugging.

Re: SwiftUI After 7 Years

#73

Post by cloogshicer »

mpweiher wrote: post #56
skydhash wrote: post #16

Earlier quoted context omitted.

I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs). React works well, because it's only an abstraction over the real DOM. Reac…

Not just does the computer not do functional. UI is also very much not functional, and in fact the lack of progress in UI the last 30-40 years can largely be traced to trying to create UI with procedural/functional programming languages, an instance of linguistic-architectural mismatch. Further reading: Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering -- Stéphane Chatty.…

Thanks for those links! Some of it was great reading.

What is your thesis then? What is UI?

Re: SwiftUI After 7 Years

#74

Post by palata »

Maybe unrelated, but as an Android dev, a few years ago I wanted to look into SwiftUI.

But now I feel like for most apps, I should be fine with Compose Multiplatform and Kotlin Multiplatform. I don't see the point of learning SwiftUI anymore.

Re: SwiftUI After 7 Years

#75

Post by peheje »

Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic.

The boundaries aren’t perfectly clean, and that’s fine. But the separation gives you a useful way to think: structure this first, style it later, add behaviour where needed.

My experience with Compose—though I suspect SwiftUI people will recognise the feeling—is that I have to think about everything, everywhere, all the time.

Then we add some MVVM/UDF flavour. The "ViewModel" knows nothing about the view, despite usually serving exactly one screen. Add some "MutableStateFlow"s, combine them into "ScreenUiState", expose it as a "StateFlow", collect it with lifecycle awareness.

Beautifully decoupled. Extremely testable.

Then the organisation writes no unit tests and relies entirely on two-hour nightly screen tests.

A welcome-page refactor breaks the profile page.

“Didn’t you check the nightly build?”

No. It runs at night.

“Well, that’s your responsibility.”

But you broke it.

“Yes, but it’s your code.”

Then why did we ship it?

Fine. Schedule the postmortem with my mother.

And I’m not blaming mobile developers here. I’m frontend, backend, full-stack, I think AI engineer now. I have personally helped make simple things complicated across the entire stack.

What I like about the web is that one simple screen can be vanilla JavaScript. Another can use Vue. Another can use some specialised spreadsheet component.

People react to that with horror: what if components are duplicated, behave or look slightly different?

Fair concern. But that is real coupling with visible consequences and trade-offs. Somehow we have started treating coupling as something abstract that only exists inside code, rather than something that should produce an actual benefit when removed.

HTML. CSS. JavaScript. Or something close to it.

Maybe I’m getting old.

Re: SwiftUI After 7 Years

#76

Post by sandoze »

zer0x4d wrote: post #64

SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps. 1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each m…

Just a couple points because your opinions aren’t wrong, they’re just your lived experience.

2. There’s no magic here. There is poor documentation. The biggest trick — small views, think about what values are going to trigger a refresh. Avoid cascading view refreshes.

6. You might have missed a couple big iOS releases (iOS 7 was one to remember) where many of our apps fell over in UIKit. Swift was another ‘DOA’ for YEARS with the same issues you’re making here, each new version broke the old, but here we are in a day and age where it’s the standard.

Re: SwiftUI After 7 Years

#77

Post by blltprfmnk »

spacedcowboy wrote: post #51

Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit. Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux

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 hands guiding that ship could have led to something great instead of the mess that is there today.

Re: SwiftUI After 7 Years

#78

Post by mpweiher »

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…

Not just complex. Also "successful for other reasons". And of course the RDF is particularly strong in Apple's case. And these are interlinked as well: they were successful in the past not just despite ignoring feedback/outside advice, but often because of it.

Re: SwiftUI After 7 Years

#79

Post by mpweiher »

palata wrote: post #72
zer0x4d wrote: post #64

SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps. 1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each m…

Apple seems to be loved by users, but hated by developers (and for good reasons). They just seem to not give a shit about the developer experience. You mention some examples, I have experience with lower-level stuff: terrible. Poorly documented, and actually not really working well. IMO they should focus on improving the developer experience instead of wasting money on the joke that is Liquid Glass (even users don't…

This used to be different. NeXTstep and early MacOS-X were pretty much the finest platforms to develop on.

Re: SwiftUI After 7 Years

#80

Post by mpweiher »

kodebach wrote: post #59
rudedogg wrote: post #49

Earlier quoted context omitted.

> functional programming is superior for representing state in user interfaces It's always going to be slower than using something imperative. Trying to process the entire world's state for the sake of purity can feel elegant but it isn't free. And the complexity that gets added to make things performant is worse than just accepting that UIs are going to require you to jump around the tree and modify state. Every tim…

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.

Post reply on HN