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.

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

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

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 only have to look at the iPhone fucking 17 to know Apple is long gone.

I was just thinking more or less along these lines - I haven't been in mobile apps for a few years now, but back then my impression was -

SwiftUI is great for "surface level" UI, that has some basic data bindings - think a basic CRUD app, which needs some navigation, and the ability to scale across the smallest iPhone to the largest macOS screen, from touch gestures to mouse input.

If you ask anything more of it, then you need to start branching off into specific libraries / tools / frameworks (UIKit, CoreAnimation etc) - which is much easier now too, but you'll always have a bad time if you try to mix the two in a single "view" / "frame".

I'm not surprised that's still true today.

It's a popular controversy here much the way React is a popular controversy here: people dabble in the new idiom but don't solidly master its basics; chaos ensues and consequently resentment.

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

I think open source is the right move here. The great thing about Flutter is you get the declarative UI to build a lot of standard screens easily but you can always drop down to lower levels, inspect the standard components, mix and match with your custom implementation. You can mix UKit and SwiftUI but there’s way more friction due to the closed nature of the SDK.

Do you have an example of where "the ideas don't combine well"? Or where an imperative approach is truly better?

In my experience the solution is often to use the appropriate architecture underneath your UI layer. Basically you build a data structure that represents your UI and always hand this entire structure to the declarative UI layer. Underneath the UI layer, you can still use imperative code to manipulate the data structures. The benefit of the reactive/declarative approach is that you don't have to think about how changes in the data need to be reflected in the UI. That's the framework's job.

Note: With "data structure" I don't mean "build a shadow DOM". I mean something specialized to your use case.

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.

Having written actual apps with AppKit, it is horrendously complicated for simple things.

Swift is incredibly better than ObjC on so many ways it’s just not comparable. I used it since day one and never looked back. (And I was deep into the ObjC ecosystem, having written very low-level frameworks, and having loved it.) Yeah, first versions of Swift were raw, but now it’s just THE language; I used for everything (obviously Apple soft frontend, but also the web, the backend, etc. Even android dev I would do with Swift though I do not have the occasion for now.)

Apple will never drop ObjC support IMHO. But most new frameworks will be Swift-only.

SwiftUI is a step backwards from AppKit in the sense that we lose control over what’s possible when using it exclusively. But 1/ it’s much simpler for doing simple things and 2/ we can drop down to AppKit when needed. All in all, it’s good that we have it.

Apple will likely never drop Obj-C, but it's been a secondary language for years now. New frameworks are all written in Swift, Obj-C is only used for existing Obj-C codebases.

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

> 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 skill up and learn to write effective and idiomatic SwiftUI.

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.

Apple has been adding Observable support to UIKit as well, so it's easier than ever for state to be the source of truth in UIKit too. Anyone writing more than simple UIKit apps has known that for a long time, it's just big a huge pain to actually implement without a lot of custom code or a dependency like RxSwift. If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.

Personally, SwiftUI makes the 80% so much easier that, even if the remaining 20% requires dropping down to UIKit, it's worth it.

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

It’s also not possible to make super bespoke interfaces without going against the grain of the framework: anathema to old school AppKit and UIKit devs.

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

I love Auto-Layout so much.

> There are hundreds of thousands of apps in the App Store that are 100% SwiftUI. They are real. And they are very much "production grade"

The first is a statement of quantity, the second is a statement of quality, dubiously supprted by the first.

The Mac Settings app still lags between panes years after it was redesigned to look like iOS. I would think that if they had a viable way build a high quality and performant app with even relatively basic UI components (if they cared to do so) they'd do it for the 1 app that's deployed to every mac.

SwiftUI does work in certain circumstances, and does work for allowing people to shit out their ideas faster, but it has struggled with the aspects described in the video. Some companies don't care either, and turnaround time is paramount, but in this discussion it's about quality compared to what came before.

Yes because SwiftUI is way more self contained and minimally verbose, it’s a better fit for LLM use than AppKit/UIKit

Some new platform capabilities are only available in SwiftUI. But you can wrap that for use in UIKit.

Agreed. SwiftData is terrible for anything more than like 2 "Models". I have a bunch of apps written with SwiftData and a bunch more with GRDB... I hate touching the SwiftData ones.

To be fair CoreData was always a footgun as well

SQLiteData is the winner.

I think you might have meant UWP.

WPF is still around and have been spruced up as of late.

UWP was the DOA Windows 8/8.1/10 app format that was super restrictive, strange to develop for, and non-portable. It's basically MS's equivalent of SwiftUI.

WPF was abandoned at birth, it went years without any attention and then was superseded.

Apple has at least been consistent on UI frameworks.

WPF was stamped out by lack of dogfooding = inability to inspire confidence, and then Microsoft spazzing out with that clusterfuck that was the Windows 8 "Metro" bullshit.

Back when I wanted WPF to succeed, Microsoft was barely using it in any of their own apps.

Apple has used SwiftUI in their OS more than MS/Windows did, and there's quite a few apps on the App Store that -seem- to be made with SwiftUI.

> With AI coding... SwiftUI lost its edge/advantage

On the contrary, I think AI has made it EASIER to approach SwiftUI now, because AI makes up for SwiftUI's biggest weaknesses: the many ways of doing everything, Apple's wonky documentation and the need to know when to fall back to AppKit/UIKit.

Yeah I don't really understand their insistence on these videos. I don't have the time to watch an incredibly hard to watch present babywalk me through the code, hoping I'd catch one modifier I missed that fixes the issue. Just write some docs for god's sake.

> There's no way I'd dare to take on a full Apple-platform app project alone on my own, but I've started dabbling in it again thanks to AI: Codex even converted an old app I made in Visual Basic 900 years ago and had it running in SwiftUI within minutes!

You may like my project https://charleswiltgen.github.io/Axiom/ (FOSS). I was in the same place a year ago, and initially created Axiom as a private skills suite before deciding that it was too helpful not to share.

> There's no way I'd dare to take on a full Apple-platform app project alone on my own

And that's really sad, because earlier Mac OS X (and even OPENSTEP to a degree) was an Eldorado for boutique developers, not least due to frameworks like Cocoa and Objective-C (despite all the hate it seems to get).

If you knew C, it was not hard to grasp Objective-C (at least it was much easier than say C++ and MFC on the Windows side of things).

1. It's not really the builder pattern, which, in Java, is what you describe as wanting: mutating a single instance. SwiftUI uses result builders to compute a single generic View from the "DSL", but you could do the same thing without the custom syntax, it would just be more verbose.

2. Documentation issue. The lifecycle is standardized, but Apple is terrible as documenting it all in one place. I found this year's "Dive into lazy stacks and scrolling with SwiftUI" WWDC video actually had a pretty good explanation, at least for the lifecycle within lazy containers.

3 and 7. Yes, Apple's tools suck pretty bad. Preview canvas is also still terrible, despite multiple attempts to improve.

4. Not something I've experienced, not sure what you mean.

5. Yeah, Apple's docs suck.

6. Not sure what you mean here either, our stuff looks pretty much the same.

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.

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.

I know people would dismiss this, but I'm going to try to make the case for Qt - I'm currently converting my note-taking app to mobile and it's going very well.

There is no right way :)

SwiftUI is good, albeit not without issues, as long as you tolerate them. The same is true for any approach. My most recent app was built in SwiftUI because I have been using React Native in my professional work for so long I wanted a change of scenery.

Each approach has its issues, and it all boils down to a matter of preference and which tradeoffs are appropriate for the project.

What I like about Kotlin Multiplatform (KMP) vs Flutter is that KMP is not a framework. For instance, I can write a KMP library and a "pure" Android or iOS app can pretend it is a "pure" Android/iOS library.

That is, pure native apps, can integrate KMP libraries. They cannot integrate Flutter libraries.

In other words, if I write a KMP library, I can ship it for multiple platforms and developers can use it in their Flutter project, or in their pure Android/Kotlin project, or in their pure iOS project.

Flutter is not the "right way", due to the nature of Flutter being a lousy reimplementation of a UI frameworks.

I wonder what experts think of this other option: going fully native for one platform then vibe-porting it to others.

I developed a complicated app in Flutter and it’s one of the best engineering decisions I made. Flutter is great.

Neither.

Flutter has been a great success for us.

Define right, it’s hard to replicate the native UI especially Liquid Glass on iOS because it’s rendering everything using its own rendering engine, making it hard to feel right on iOS. I have also seen a lot of companies move away from flutter to either native or React Native.

https://en.wikipedia.org/wiki/Poe's_law

I joked, but reading the post is even more clear - man this poor dude.

He is brute forcing his way through life and broadcasting it on YouTube.

Dunno man, Xogot is made up of almost half a million lines of code. Of those 727 files use SwiftUI, and 65 use UIKit, 119 use AppKit (I did not count the overlap, so they are not mutually exclusive).

Using GeometryReader makes it clear he is living in the past and the fact that he uses printChanges in this year without mentioning the dedicated SwiftUI instrument show a lack of curiosity on the space.

Somehow you being the GNOME co-creator made me curious about what the GTK/GIMP creators (Kimball, Mattis) are up to. CockroachDB, it seems. It's weird how it's so easy to miss these connections.

Well you could do android apps using SwiftUI ¯\_(ツ)_/¯