Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

281–290 of 343 posts

Re: SwiftUI After 7 Years

#281
I shipped an internal company application using SwiftUI a couple of years ago and the author pretty much nailed all of my pain points. At the very least in JavaScriptLand™ you are provided very opinionated ways to go about reactivity: choose your framework flavor and start shipping. In SwiftUI, you have all of these declarative macros, some of which do the same thing, so you spend hours going over whether you should do MVVM or MVC or some other thing to structure your code instead of actually writing the code.

It wasn't mentioned in the article but half if not more of swiftui's issues also stem from XCode being the worst IDE to work with. It's incredibly bloated, tries to drive you towards GUI-driven interactions instead of using CLI, and takes ages to explore and understand all the different features/settings. I've never had any other IDE or editor refuse to compile my code because of a memory overflow during the compilation step, yet for some reason, even when compiling swift on an M2 MAX with 64GB of ram in 2026, I regularly get these kinds of cryptic errors that tell me it can't compile. Likely due to misuse of some code expansion feature, but then it rarely tells me where the source of misuse is.

Re: SwiftUI After 7 Years

#282

Earlier quoted context omitted.

If you dont believe me… nobody is stopping you from testing various things on the same model? And if you dont have it already… then what could I possibly say that would motivate you to buy a used one to do the testing to confirm? Edit: And even on my ipad pro m2 doing literally nothing other than swiping to the app library often causes a visible stutter and lag for hundreds of miliseconds… so if you really think it’s…

Why should I need to do any testing ? I'm just going to keep on not believing you until you back up your claims. And your iPad example doesn't make sense at all, you compared 2 Macbooks and now you're talking about another OS altogether. > idk what to say. You could just tell us one example of something that's faster on your 2019 Macbook Pro 15 versus a M5 Macbook pro and how to reproduce it.

If you dont ever intend to do any testing… then why would anyone care about what you believe or not?

Why post random noise opining?

Re: SwiftUI After 7 Years

#283
post #62

This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc. Data Flow: The author claims there’s no way to know when things update. Not only does experience help…

"@environment is super cool" Strong disagree on that. @environment is an amateurish hack, basically sugar-coating global variables as a solution to SwiftUI's poor design. I had a strong background in UIKit; then for a product I'm building for myself, I decided to go all-in on SwiftUI. This was after it had been around for four years or more. SwiftUI turned development, which I used to enjoy and feel good about, into…

> The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype. Look at the examples for this thing: They're applications that present a stack of views that each show... an INTEGER. In decades, I have never written an application that needed to stack up a pile of views that all show the same datatype.

You should probably read more of the documentation than looking at examples, "to create an array of one datatype" its far from the truth. NavigationPath can be use to route to more than one type https://developer.apple.com/documentation/swiftui/navigation...

Re: SwiftUI After 7 Years

#284

Earlier quoted context omitted.

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

Settings lags not because of SwiftUI but because it renders all the panes out of process

I think it's a little of both, but last time I tried making a performant NavigationView/NavigationSplitView/VStack like that, it chugged along compared to the same layout built with AppKit

Re: SwiftUI After 7 Years

#285
post #195
post #145

Earlier quoted context omitted.

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…

I remember this video, from way back. Then, it was impressive, but it also felt logical that machines of that era were able to do it. So it wasn't magic. Just good engineering. Now everything is jank & stutter and my 64GB 25 times more powerful machine just refused to play back a YouTube video in my Safari tab since I have too many windows open.

I knew Apple was lost when they dropped the “Home” button, just after spending a $1B to build a Palo Alto headquarters in the shape of the “Home” button.

Re: SwiftUI After 7 Years

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

It is a generation thing, all the folks that were able to ship those products are now retired, or approaching retirement, and apparently newer generations can only do Electron, React Native and co.

Re: SwiftUI After 7 Years

#287
post #122
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…

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…

It only worked that way for Steve Jobs, because under him, as it was at NeXT as well, either you dedicate your life to the cause, or go work elsewhere.

Re: SwiftUI After 7 Years

#288
post #195

Earlier quoted context omitted.

I remember this video, from way back. Then, it was impressive, but it also felt logical that machines of that era were able to do it. So it wasn't magic. Just good engineering. Now everything is jank & stutter and my 64GB 25 times more powerful machine just refused to play back a YouTube video in my Safari tab since I have too many windows open.

I knew Apple was lost when they dropped the “Home” button, just after spending a $1B to build a Palo Alto headquarters in the shape of the “Home” button.

I suggest reading Steve Jobs biographies regarding those kind of expenses at Apple, Pixar and NeXT.

Re: SwiftUI After 7 Years

#289

Earlier quoted context omitted.

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.

> Whatever it is, SwiftUI isn't it. I think this opinion is heavily shared by Swift developers now, but the messaging every WWDC is always "Swift and SwiftUI is the best way to build apps for Apple Platforms", etc.. If you have to keep telling everyone what they don't believe is true, it's a sign there's a problem. It feels like someone with a lot of organizational power is disconnected from the pulse of the communit…

If you want to see this behaviour dialed to 11, check how Microsoft management talks about WinUI 3.0, and the harsh reality of its sore state of development experience.

It would be great if it was half as bad as SwiftUI.

Re: SwiftUI After 7 Years

#290

Earlier quoted context omitted.

Well the problem now is Apple would need to admit they made a mistake. And Apple does not make mistakes.

Yes, they don't ever openly admit mistakes. But they do quietly drop or fix them, covertly acknowledging they were mistakes. Often with this messaging: "we have this new shiny thing that is even better than the old shiny thing (that was really a turd)". Remember "garbage collection"? Or "modern syntax"? Or CocoaJava? And with hardware they had their "come to Jesus" moment a while ago. And then hit it out of the ballp…

CocoaJava was when they were not certain devs educated in C++ and Object Pascal would ever accept Objective-C.

Garbage collection is still there, regardless of the marketing message without fundamentals from CS theory of automatic memory management algorithms, because they need to blame something else other than themselves, Apple does no wrong.

Post reply on HN