[rayiner]

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 the company that shifted from Toolbox to Carbon to Cocoa and each step was better than the last. Could Apple build MacOS X and Cocoa today if they didn't already exist? Microsoft's two decades of failure to ship a true successor to Win32 suggests that Microsoft (at least, the operating system side of the company) died a long time ago. I wonder if we'll say the same thing about Apple 10 years hence.

[steve1977]

I think the problem with SwiftUI in a way was (or is) that Cocoa was so good. And, at least IMHO, it didn't need replacing, just improving.

But I feel like Apple wanted to appeal to young web devs and tried to offer something more similar to what these are used to.

[monster_truck]

Totally agreed. I kind of figured things were going to get shitty when the guy who made autolayout got hounded on so hard that he left.

I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it.

[rudedogg]

> Whatever it is, SwiftUI isn't it.

I think this opinion is heavily shared by Swift developers now, but the messaging every WWDC is always "Swift and SwiftUI is the best way to build apps for Apple Platforms", etc.. If you have to keep telling everyone what they don't believe is true, it's a sign there's a problem.

It feels like someone with a lot of organizational power is disconnected from the pulse of the community. SwiftUI is undeniably clean in a lot of ways, it presents beautifully and fits on slides well, but that matters less and less, and this all wasn't really working out even before LLMs disrupted things.

[steve1977]

Well the problem now is Apple would need to admit they made a mistake. And Apple does not make mistakes.

[refulgentis]

It’s a seductive idea, but it displaces who is responsible for the poor framework development onto users of the framework.

It’s easy to say they were just trying to be trendy and thus the real flaw was the trend is bad and the fault of worse devs than us (the young web devs mentioned)

The thing that obviates that is the trendy stuff works, yet, SwiftUI doesn’t.

(source: I wrote ObjC/Cocoa as early as 2006, and switched to Flutter as my primary dev kit some years ago: it simply doesn’t have the performance issues mentioned.)

[mpweiher]

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.

[skydhash]

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. React only handles your app state. But the DOM mechanism is still very performant and very much imperative. But I don't think something like React would work well in a mobile app, because the UI tree is often very simple on iOS and macOS.

[mpweiher]

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.

https://link.springer.com/chapter/10.1007/978-3-540-92698-6_...

Can Programmers Escape the Gentle Tyranny of call/return?

https://2020.programming-conference.org/details/salon-2020-p...

UIs Are Not Pure Functions of the Model - React.js and Cocoa Side by Side

https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status

https://2024.splashcon.org/details/splash-2024-Onward-papers...

[cloogshicer]

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

What is your thesis then? What is UI?

[torginus]

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.

[dgellow]

Hmm, but React doesn’t own or manage the app state. And react native has been used for pretty complex applications

[poly2it]

Functional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai:

https://github.com/janestreet/bonsai

[rudedogg]

> 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 time I go through the trouble of understanding the latest web technique (React, Elm, Signals (the newest solution), etc.) to deal with state management and the DOM, I end up walking away disappointed. There's nothing new in them that you can use to improve what we've been doing for ages in native GUI toolkits.

And to jump back to the original topic, yes, Cocoa was pretty decent, and SwiftUI while nice in many ways tries to Reactify native macOS development and made it worse. And it made Swift incredibly more complex and worse in hindsight.

[kodebach]

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.

[mpweiher]

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.

[mpweiher]

Not sure how you define "success" here. Is Bonsai used much outside of Jane Street?

[skydhash]

> Functional doesn't mean stateless.

I didn't say that.

User interfaces representation are mostly trees. And with functional programming you basically have Tree2 = f(Tree1). Until f is done you can't do anything really. React has a lot of escape hatches to improve performance, but they are escape hatches, not an endorsement of the architecture.

With imperative programming (and OOP), you only have that single `Tree`, which you update at will. Less elegant yes, but we have modularization to help us there. What Emacs does is to keep that `Tree` as a single mutable object, but have the code be functional, while the results are imperative.

[brnt]

I only have to look at the iPhone fucking 17 to know Apple is long gone.

[graypegg]

Genuinely curious, what’s wrong with it?

I’m no huge apple fan, but I didn’t really think the 17 was more than a regular boring spec upgrade, which seems fine all things considered. (Currently on an iPhone fucking 17)