Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

41–50 of 343 posts

Re: SwiftUI After 7 Years

#41
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…

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

Re: SwiftUI After 7 Years

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

Re: SwiftUI After 7 Years

#43

Is the right way to develop mobile apps flutter? or Kotlin multiplatform plus native UIs?

Flutter has been a great success for us.

Same here, but Liquid Glass has been a headache lately. Google really dropped the ball here, but to their credit it almost feels like Liquid Glass was an intentional move by Apple to cause as much friction for cross platform frameworks as possible.

Re: SwiftUI After 7 Years

#44
post #5

I fell in love with SwiftUI the day it was announced, but as a solo dev I still haven't been able to make a full app with it yet, mostly because of the lack of documentation, and the gaps where you still need to drop down to AppKit/UIKit. I went through Visual Basic, .NET, WPF, Cocoa, and other random frameworks all professing to be the promised panacea for UI, but I think SwiftUI+SwiftData is the best environment ev…

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

That's actually why I jumped from Windows to Mac in the first place!

My first Apple purchase was an iPad I got for my aunt, and I loved how streamlined yet powerful it was so I installed a VM on Windows to dabble in iOS development, and fell in love with the sheer consistency of macOS, iOS and their APIs.

This was during the era when Microsoft was still figuring out whether to keep the Start Menu and replace the whole Windows UX with a tablet UI, so it was an easy jump.

Almost never looked back, and whenever I do I'm glad I jumped.

Then came Swift and I loved it, but then it took literal years to catch up with everything you could do in Objective-C with the Apple APIs. SwiftUI is having the same problem but for much longer :(

Re: SwiftUI After 7 Years

#45

A similar story to WPF.

WPF was abandoned at birth, it went years without any attention and then was superseded. Apple has at least been consistent on UI frameworks.

Sort of superseded. In practice WPF is still very often the best option in the complete mess that is window GUIs

Re: SwiftUI After 7 Years

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

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)

Re: SwiftUI After 7 Years

#47
post #25

SwiftUI it is the type of framework that makes the easy things easier to accomplish but the harder things harder. It is a newbie trap. It is great at producing simple apps, or things that don't require intense scrolling, or anything with heavy animations and precise layouts, but when you do something smooth, it is not it. It feels more of a React Native competitor, than a true UIKit replacement. Also, almost everythi…

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

Maybe for you. But SwiftUI promise was to make coding UI easier for the programmer similar to ReactN, but with AI coding that is not necessary anymore, you can go straight to UIKit which is most stable and feature complete.

In car terms:

UIKit - Manual Transmission - you control everything, but a bit of a chore

SwiftUI - Slushbox Auto Transmission - easier to drive, sucks for performance

UIKIT+AI Coding - Dual Clutch Transmission - both great performance, and easy to control/drive

Re: SwiftUI After 7 Years

#48
post #15

SwiftUI is gold compared to SwiftData.

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.

Re: SwiftUI After 7 Years

#49
post #20

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…

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

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

Re: SwiftUI After 7 Years

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

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.

Post reply on HN