Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

141–150 of 346 posts

Re: SwiftUI After 7 Years

#141

Post by lilbigdoot »

steve1977 wrote: post #26
rayiner wrote: 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.

I never really tried out Cocoa. What did you like about it?

Re: SwiftUI After 7 Years

#142

Post by ardit33 »

bsder wrote: post #137
mpweiher wrote: post #56

Earlier quoted context omitted.

Not just does the computer not do functional. UI is also very much not functional, and in fact the lack of progress in UI the last 30-40 years can largely be traced to trying to create UI with procedural/functional programming languages, an instance of linguistic-architectural mismatch. Further reading: Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering -- Stéphane Chatty.…

> UI is also very much not functional, I disagree, and I believe that the complete stagnation of GUIs is due to ignoring this. There is no good reason why a GUI system isn't: Description->Pack->Apply events->Generate assets->Render assets. At each point you reify the result into an artifact that is everything the next stage needs. This has a couple of nice properties. One property is that everything is deterministic…

You are applying a one way arrow to events where in real life events do change state and can completely change UI (and functions) itself. Which makes imperative always the superior mode.

What you described works only in super simple scenarios. Whink Web 1.0, when Javascript was used for basic form validation at best, and didn't change DOM that much.

Re: SwiftUI After 7 Years

#143

Post by ardit33 »

mpweiher wrote: post #80
kodebach wrote: post #59

Earlier quoted context omitted.

The goal of the reactive/declarative approach was never to be more performant than imperative code. The goal is to more easily build UI that is performant enough and functions correctly . With imperative UI code it is incredibly easy to forget an edge case in your update logic.

Not if you actually do MVC, so solved around 50 years ago. 1. The UI tells the model to change. 2. The model does the change and possible related changes. 3. The model notifies the UI that something has changed. 4. The UI updates itself from the model. Alas almost nobody does MVC, despite calling what they do MVC.

Dude, you didn't describe MVC at all, but MMVC.

MVC, the controller is the intermediary between the services/data models, and the views. That still one of the best / simplest way to build large apps. MMVC is just a variation of it, with the models being able to communicate state to views and bypass controller if needed.

MVC, is still one of those 'fundemental as simple as it gets, and it gets the job done' patterns.

Re: SwiftUI After 7 Years

#144

Post by ardit33 »

joshuakcockrell wrote: post #124
spacedcowboy wrote: post #51

Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit. Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux

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

Just use manual layout / frames dude, like a caveman. (ps. Many successful large apps do just that, including Instagram, and some of Spotify, where I worked).

Re: SwiftUI After 7 Years

#145

Post by ksec »

ardit33 wrote: post #138
ksec wrote: post #122

Earlier quoted context omitted.

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…

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 without Steve Jobs the first time round. On paper there are a lot of cool tech being worked on. But in the end it was tech from NeXT that really shines.

And a lot of these tech don't actually benefits the customers. If the choice was a language and framework that is slightly harder to developers but brings overall higher quality Apps because the barrier is higher. Compared to a language that wants to replace Assembly to Javascript while being easy to learn like Visual Basic and for everyone to code. I would much rather pick the former.

Edit: I suddenly remember I also submitted a Core Animation introduction video from Steve a while ago on HN [1]. 20 years later we have gone backwards on a lot of things.

[1] https://x.com/lucaslovexoxo/status/2082098579632783441

Re: SwiftUI After 7 Years

#146

Post by Razengan »

Razengan wrote: 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…

P.S. Re: AI, I don't mean outright generating entire apps from a single sentence (except for conversions of private tools), but using AI to navigate Apple's obtuse documentation and edge-case APIs, i.e. "how to do this"

Re: SwiftUI After 7 Years

#147

Post by ardit33 »

sampton wrote: post #15

SwiftUI is gold compared to SwiftData.

SwiftData is just a framework that you can choose to ignore and not use at all. Even CoreData. You can go straight to the source, and use some small layer on top of SQLite, and ignore that noise (most large apps just do that).

But, SwiftUI is being pushed as the way to do UI, and as a replacement for UIKIt/the future of apple, where it is not even near feature parity with it. That's the most troubling part of it.

I wished apple just made it as a Template Rendering framework, and integrated wit with UIKit, and just modernized UIKit a bit.

Re: SwiftUI After 7 Years

#148

Post by simondotau »

zombot wrote: post #131
rayiner wrote: 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 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.

That wasn't the question though. Being able to say it today doesn't mean you will be able to say it in 10 years. Companies which lose their way sometimes rediscover themselves. One example that comes to mind is Apple. Another example that comes to mind is Apple.

In fact I can think of at least three instances (at very different magnitudes) where Apple has dragged itself out of a stupid hole they dug for themselves.

Re: SwiftUI After 7 Years

#149

Post by willtemperley »

VerifiedReports wrote: post #135
sandoze wrote: 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.

You can use a tagged union for the "one datatype", thereby allowing your views to accept any datatype you provide in the enum. Or use NavigationPath.

Re: SwiftUI After 7 Years

#150

Post by mac-mc »

ardit33 wrote: post #138
ksec wrote: post #122

Earlier quoted context omitted.

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…

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…

I wrote something similar a couple years ago too after having a pretty bad time with swift ui and concurrency: https://medium.com/goodones/pareto-optimal-apple-devtools-b4...
Post reply on HN