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

Why I quit using SwiftUI

chsxf.dev

Post reply on HN
Print view View original

21–30 of 257 posts

Re: Why I quit using SwiftUI

#21

Post by rudedogg »

aaaaaaaaaaab wrote: post #18

People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions) I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, w…

> They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff.

At WWDC 2022 they specifically said that Swift+SwiftUI is the best way to build apps, and the future of their platforms. I thought AppKit/UIKit would stick around, but I guess not.

---------------------------

Edit: Here's the direct quote from the "Platforms State of the Union":

> We're continuing to expand our adoption of SwiftUI across our apps and system interfaces. For example, iOS's new Lock Screen widgets were designed from the ground up using SwiftUI. The new Font Book app was completely rewritten with it. And the modern, forward-looking design of the new macOS System Settings app was built using it. Swift and SwiftUI were designed from the start to provide a single, native language and API for all Apple platforms. You can learn them once and apply them everywhere. Whether your vision is to provide quick access to information at a glance on Apple Watch, productivity tools on MacBook Pro and iPad, new experiences on iPhone, or a new way to relax with Apple TV, Swift, SwiftUI, and Xcode provide a next-generation integrated development platform to help you build apps for all of our products. Now, if you have an existing app, it's easy to adopt these new technologies incrementally. And if you're new to our platforms or if you're starting a brand-new app, the best way to build an app is with Swift and SwiftUI.

The slide had a Swift, SwiftUI, and Xcode logo with nothing else.

Re: Why I quit using SwiftUI

#22

Post by jollybean »

solomatov wrote: post #16
dmitriid wrote: post #6

> I profiled the whole thing and discovered several things. First, the view provided by the selectable object was completely recreated with every redraw. I gained some performance back by caching it, but things remained barely usable. That... is exactly the same thing with React. You don't notice everything is redrawn until suddenly everything is unbearably slow. And then it's useMemo etc. galore. I'll withhold my ju…

IMO, you shouldn't use React-like tools in performance critical UI code. Direct DOM manipulation in such cases is much better and more maintainable option. I.e., it's easier to maintain straightforward direct DOM manipulations than all the tuning around making a React-like system more performant.

Then why use it anywhere?

I have never fully bought into this notion that the components should rebuild themselves in this kind of stateless manner.

I think this like an intellectual obsession with functional programming mapped onto the UI Tree. I can't fathom why it's 'better'.

The reactive aspects of the middle tier of the program - that's progress. But the reactive components, I'm not sure about that.

Re: Why I quit using SwiftUI

#23

Post by GrabbinD33ze69 »

bsaul wrote: post #19
retskrad wrote: post #7

People nowadays praise Apple for their hardware, mainly their silicon - not their software. Maybe it's time for Apple to shake things up and promote someone else to VP of Software engineering?

I’m with you, however mac os remain the best dekstop OS and iOS remain the best mobile one, even after all those years. So, they must be doing something right..

I agree, in my experience, MacOS is one of the most reliable operating systems I've used in terms of lack of crashes or spurrious bugs; the most common bug I see is my mouse pointer dissapearing, which is fixed by opening the tasks view.

Re: Why I quit using SwiftUI

#24

Post by jmull »

The declarative, "reactive" approach is good, and worthy of rolling out a new UI API even given that Apple has an excellent MVC-style API...

But it looks like the task was somewhat beyond the people who had the responsibility for rolling out SwiftUI at Apple.

We're several years in to SwiftUI.

Apple's in a tough spot now. I'm really glad I don't have anything too high-stakes dependent on it. (I only have a project with ~200 hours invested -- not zero! -- it's heavily UI, but it's tiny... maybe ~30-40 hours to port to UIKit, if needs be.)

Re: Why I quit using SwiftUI

#25

Post by bowsamic »

socialdemocrat wrote: post #11

I spent only about half an hour with Swift UI to decide it was bot worth it. Looks sleek but the underlying technology is too complex IMHO.

I agree. The amount of plumbing behind the scenes is really complex. This immediately becomes apparent if, for example, you want to use @AppStorage with something that isn't a very simple type. Then suddenly you are in no mans land reading Combine documentation with no examples

Re: Why I quit using SwiftUI

#26

Post by ChrisMarshallNY »

I like what SwiftUI will become, but I'm not there. yet.

The current project that I'm working on, is pretty big. It peaked at 40 screens, but I'm trying to get it down to half that.

I've been working on it for two years. I also wrote one of the backends (and most of another).

There was no way that I was going to start on a project of that complexity on SwiftUI, which, at the time I started, had only been demonstrated in a few small projects. I already knew that UIKit could do it.

But I think that SwiftUI will become the standard, sooner or later. I look forward to being able to write more reactive applications in it. In my experience, if I use UIKit, it's a fairly bad idea to stray from the old MVC model (This, I have learned. See this scar?).

Re: Why I quit using SwiftUI

#27

Post by heavyset_go »

elpakal wrote: post #5
jph wrote: post #2

SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of…

> but at the same time the docs are terribly lacking at how to handle any kind of edge cases. I agree that Apple’s documentation needs help (this year’s improvements are a nice step) but can we really expect them to provide extensive documentation for handling edge cases (you’re telling me UIKit docs offer that)?

Yes, I expect a trillion dollar company to invest in good documentation of their dev products.

Re: Why I quit using SwiftUI

#28

Post by bowsamic »

rudedogg wrote: post #21
aaaaaaaaaaab wrote: post #18

People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions) I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, w…

> They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, while keeping UIKit and AppKit for serious stuff. At WWDC 2022 they specifically said that Swift+SwiftUI is the best way to build apps, and the future of their platforms. I thought AppKit/UIKit would stick around, but I guess not. --------------------------- Edit: Here's the direct quote from the "Platforms State…

There is no evidence to suggest that Apple are deprecating AppKit and UIKit

Re: Why I quit using SwiftUI

#29

Post by solomatov »

jollybean wrote: post #22
solomatov wrote: post #16

Earlier quoted context omitted.

IMO, you shouldn't use React-like tools in performance critical UI code. Direct DOM manipulation in such cases is much better and more maintainable option. I.e., it's easier to maintain straightforward direct DOM manipulations than all the tuning around making a React-like system more performant.

Then why use it anywhere? I have never fully bought into this notion that the components should rebuild themselves in this kind of stateless manner. I think this like an intellectual obsession with functional programming mapped onto the UI Tree. I can't fathom why it's 'better'. The reactive aspects of the middle tier of the program - that's progress. But the reactive components, I'm not sure about that.

>Then why use it anywhere?

To write code quicker, and make it easier to maintain. If it's a moderately complicated UI, then I could code it up much faster in React (my guess is around 10x). IMO, React isn't about functional programming, it's just a good DSL for writing UI.

Re: Why I quit using SwiftUI

#30

Post by bowsamic »

bsaul wrote: post #12
TazeTSchnitzel wrote: post #8

The post didn't go into much detail as to why it seems to be so slow. Is SwiftUI recreating an entire UI's worth of components when a state update happens?

To me that’s the red flag. That an experienced game developer wasn’t able to properly troubleshoot down to the correct level, but ended up facing a black box and gave up.

Well that's supposed to be the point of SwiftUI. You write out your declarative structure, let the library worry about how to make it fast, and move on with your day. They literally introduced it that way. Obviously that is very detached from reality
Post reply on HN