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…
SwiftUI After 7 Years
41–50 of 343 posts
Re: SwiftUI After 7 Years
#42The 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…
Re: SwiftUI After 7 Years
#43Is the right way to develop mobile apps flutter? or Kotlin multiplatform plus native UIs?
Flutter has been a great success for us.
Re: SwiftUI After 7 Years
#44I 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…
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
#45Re: SwiftUI After 7 Years
#46The 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.
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
#47SwiftUI 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.
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
#48SwiftUI is gold compared to SwiftData.
Re: SwiftUI After 7 Years
#49Earlier 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
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
#50The 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.
I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it.