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…
> 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.
SwiftUI After 7 Years
191–200 of 343 posts
Re: SwiftUI After 7 Years
#192The 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…
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 th…
What were the emerging problems that you talk about? I am actually curious because I was quite fond of the DevEx
Re: SwiftUI After 7 Years
#193If you’re just getting AI to build you an iOS app, is there any reason to use SwiftUI over UIKit?
Re: SwiftUI After 7 Years
#194> real, production-grade UI framework What does this even mean? 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 only people still complaining about SwiftUI 7 years later are the UIKit holdouts that never took the time to properly learn how to use it.
> 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 performan…
Re: SwiftUI After 7 Years
#195Earlier quoted context omitted.
I agree with you. Swift should have been a modernized Objective-C. It should have kept the best parts of it, which made it a joy to use, and leave the archaic and the weird things behind. it would have been a great language, meanwhile they decided to throw everything out and created a language that it is overcomplex, and it is failing to gain any traction outside iOS / Apple's ecosystem. Basically, if you weren't req…
While reading this comment, two of Steve Job's line pops up in my head. I think it was the Apple Park opening, and Steve response to insult in WWDC 199x. > "We need to be true to ourselves, and remember what is important, that is what going to keep Apple Apple, is if we keep us, us." > "You have got to start with the customers experience and work backwards to the technology. Right now it feels a lot like Apple withou…
Re: SwiftUI After 7 Years
#196Earlier quoted context omitted.
At least for me, it just had/has the right mix of abstraction and simplicity. It just "ticked" in a way that for example MFC didn't. But I also really liked Objective-C.
Cocoa and Objective-C are both great, but I think there's one huge problem that they never managed to solve well: responsive layouts. Classic iPhone apps have fixed layouts, and classic Mac apps have a big dynamic document in the centre with mostly fixed toolbars around the sides, and dialogs with fixed layouts. Making a really dynamic layout with OS widgets is a huge pain, so most apps sidestepped it. As Apple gradu…
Multiple 'artboards' for screen sizes/ratios are the solution, which basically just means swapping out a .nib in Interface Builder. Better to just make it explicit.
Re: SwiftUI After 7 Years
#197I get people are upset, but the edge cases and frustration in no way feel like fundamental failures—just stuff they haven't gotten around to yet. Yes, they should have gotten to them all sooner but that doesn't convince me they won't eventually.
Re: SwiftUI After 7 Years
#198> We started with @State, @Binding, and ObservedObjects. Then Apple realized the performance was disastrous and SwiftUI was re-rendering views all the time. That’s when it introduced the Observation framework and the @Observable macro. They tried to solve the problem with compiler tricks, but it clearly wasn’t enough so the layout engine continued its guessing games.
Not why @Observable was introduced
> In SwiftUI, you can never know for sure how many times a view will update and, when it does, why it chose to.
Instruments tells you these days
> That demo project from the SwiftUI tutorial has a very standard, non-custom one. You build the project with the latest Xcode and launch the app on the latest macOS—only to get this.
Yeah, it's a demo marked as "this is old, please do not use it"?
> What is a SwiftUI problem is the overall fragility of UI layouts. They fall apart in the most unexpected ways and at the most unfortunate moments. You can see it in the very real, production apps like UTM. It’s a fantastic piece of engineering, but its reliance on SwiftUI sometimes makes it feel like an early prototype.
This is an app written by someone who spends most of their time writing graphics APIs I think the fact that they can do something half-decent is really a testament to how approachable SwiftUI is
> In the end, you find yourself wrapping everything in a GeometryReader. And this is the ultimate admission of defeat.
No I only use GeometryReader when I actually want to do some coordinate math
> Okay, maybe you want to let your users customize the window toolbar, just as they could since 2001 (or something like that). Well, SwiftUI received this “breakthrough” feature only a few years ago.
iOS 14 my guy, this is literally one year after SwiftUI was released
> And then there’s the most basic task: displaying images you fetched from the network. Well, you better write your own fetcher, because AsyncImage was introduced only in iOS 15.
Can you point me at the API in UIKit that lets you do this?
> But if you want to also cache those images, I’ve got bad news for you: You can’t do it at all because right now, in July 2026, this API is still in beta.
Or this?
> For all these scenarios, developers usually come up with their own hacks and workarounds.
Yeah, it's called "you download one of a handful of libraries to do it for you". Now you don't have to do that.
Re: SwiftUI After 7 Years
#199The 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 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…
Message passing, these loosely coupled 'delegates', a mixture of hardcore C, needing to do memory management but also just passing objects around in the runtime... messy, weird... but in the end the right solution to make flexible but performant software. I learned a lot from it. I should dive into the history of NeXT one day.
Re: SwiftUI After 7 Years
#200Earlier quoted context omitted.
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.