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.

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.

The problem with ObjC was mainly syntax, bolted on over many years on top of a C core. It was grown rather than designed, and it shows. But there's nothing wrong with the runtime.

Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's performance in the process.

SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit, rather than treating them as deprecated implementation details that devs nonetheless keep having to drop down into.

These decisions come down to ego, of wanting to do away with the old and carve out your own legacy separate from it. Nice if you want a promotion but not so nice if you're trying to make a long lasting ecosystem for developers to build upon.

At least Swift and SwiftUI have a reasonable interoperability story with the past. Can't say the same about Microsoft's graveyard of UI frameworks.

The underlying problem is the programming industry completely resisting learning the lessons of Objective-C because it doesn't like them. It didn't like them when NeXT tried selling it, and it doesn't like it now.

You can't have Cocoa without Obj-C, or at least a langauge and runtime with that philosophy.

Apple software has been on a clear decline for a seriously long time, and it's propped up almost entirely by them pulling off Apple Silicon combined with how Microsoft have somehow been even worse.

> 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.

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.

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.

> I wonder if we'll say the same thing about Apple 10 years hence.

I don't think we have to wait 10 years, we can say it today.

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