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

121–130 of 343 posts

Re: SwiftUI After 7 Years

#121

Post by a34729t »

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…

They used to care about developers. Peak cocoa and uikit was a thing of beauty and objc remains my favorite programming language of all time. When Swift came along i tried and was dissapointed and then a decade later i gave it another whirl and was shocked it was still so bad. The hardware has gotten better, but the software clearly not.

Re: SwiftUI After 7 Years

#122

Post by ksec »

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…

7 Years of release on Swift UI, 12 years for Swift.

This isn't 7 years of development, but 7 - 12 years after release. And to most these past 7 - 12 years are an ongoing beta development. It is unfinished, unpolished with no end in sight. And I have been extremely critical since the beginning.

But the problem runs much much deeper. It isn't the technology that is the problem, not the devs who are making it. It is the person making the decision as to WHY this was allowed from the get go. WHY this was allowed to be released, or even before all that WHY resources for development of these ideas were allowed in the first place.

For every yes that are a thousand no. Instead a lot of Apple's software development can be summarised as resume or KPI bonus driven development. It is not as bad as Google and Microsoft, but it is clear Apple have this problem a well.

If you look back into Jobs era of Apple software, ( and not just software ) Apple manage to have done most things 2x better with half the resources. The whole Apple now is bloated. And yet everyone is chanting Craig Federighi all the way.

And it is funny because for the vast majority of these 7-12 years I was the only few on HN and Twitter that was extremely skeptical of it, to the point I gave up writing ( or ranting ) about it before majority Swift and Swift UI developers negative sentiment emerged.

And I have often asked the same question every single time, what if they just spend one fifth of the resources to iterate and improve C / Objective-C and Cocoa. All the resources on Swift and everything adjacent to it could have been better spent somewhere else.

I have high hope for John Ternus, hopefully he gets his political game right and manage to change course for Apple software somewhere down the line.

Re: SwiftUI After 7 Years

#123

Post by joshuakcockrell »

sandoze wrote: post #62

This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc. Data Flow: The author claims there’s no way to know when things update. Not only does experience help…

Complaining about needing special code to support iOS 15 definitely weakened the argument.

Re: SwiftUI After 7 Years

#124

Post by joshuakcockrell »

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

Ah yes, the glory days when you had to sift through 200+ lines of NSLayoutConstraint just to fix a simple layout bug.

Re: SwiftUI After 7 Years

#125

Post by kikimora »

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…

Famous UI = f(Model) is oversimplification that was sold in slides. Real “functional UI” frameworks implement UI = f(Model, UIState) where UIState is scroll and cursor positions, view pool for virtualization, rendering caches, etc. USState is mutable and managed by the framework and the rendering engine (e.g. React + DOM, SwiftUI + UIKit + CoreAnimation). I don’t see a problem with functional approach as in React. I do see a problem with understanding of how UIState being managed between framework, ui library and rendering engine.

Re: SwiftUI After 7 Years

#126

Post by ak39 »

dosisking wrote: post #104
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.

This type of story about management getting rid of the old guard is so common and typical, it remains one of the most frustrating aspects of this industry.

In the “enterprise scene”, this sort of purge strategy is likely linked to a big percentage of money wasted and sometimes total failure.

Why do managers keep making this mistake? “Legacy” is only a bad word in IT. :-(

Re: SwiftUI After 7 Years

#127

Post by ajpaulson »

happytoexplain wrote: post #102
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…

Any chance you have any links so I can read up on this approach?

Re: SwiftUI After 7 Years

#128

Post by dosisking »

peheje wrote: post #75

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

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

I guess I'm even older, because I prefer HTML4, without CSS. And I like using tables for layout instead of divs.

I always hated CSS.

Re: SwiftUI After 7 Years

#129

Post by zombot »

You know those games you buy as Early Access while they're still in development, with the implied promise that development will be done some day? And how many of those games have stayed Early Access over so many years that you stopped believing they will ever be done? That's SwiftUI. I won't touch it.

Re: SwiftUI After 7 Years

#130

Post by kikimora »

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.

MVC is not bad, but it is not a silver bullet. Calling MVC an ultimate solution to UI is oversimplification. Just looking at the steps you listed I can ask:

How do you collect all notifications on step 2 to fire them on step 3 such that UI does not re-render itself too much? E.g. updating a title of each item in a list of 100 items should not trigger 100 renders. Or 100 layout calculations (which I think is harder to avoid).

How do you deal with situations where on step 4 UI triggers an event that your model happens to listen and the cycle repeats while killing performance?

Because you rely on events how do you avoid “event hell”? That is, a situation when an event handler triggers a change that triggers another event handler that triggers a change and so on. Sometimes it is scrolling or typing, sometimes it is parts of the model subscribed to each other bubbling events to UI.

Post reply on HN