There is an article about this based on a Chris Lattner talk/links to previous HN discussions: https://danielchasehooper.com/posts/why-swift-is-slow/

This is absolutely wild.

Wow. I think sometimes you just don't know how things are going to turn out until you use something "in anger", as they say here in the UK. "Let's try using this fancy type-checker in a production language" is reasonable. "Let's overload + so you can combine things easily" is reasonable. "Let's allow you to express different kinds of types as a string" sounds pretty cool too. How could you know the combination of all of those would change a simple expression with an invalid type in it into a 42-second compile time with a cryptic error message, except by actually doing it?

EDIT: Meanwhile, over here in go-land, I just got annoyed that adding a new external authorization library took the average compile time of my 20k project from 7s to 9s.

I think SwiftUI is actually causing Swift a lot of reputation damage. I rarely see the issues common to moderately complex SwiftUI views when writing Swift with code-only AppKit/UIKit, for a CLI program, etc.

I jumped directly into SwiftUI for a few macOS apps I published, and the weird performance issues / UI lag / Compose complexity for even simplistic apps were hard to navigate, even after a year.

Yet rewriting components in AppKit/UIKit feels regressive since even Apple's docs migrated to SwiftUI, but sometimes that was the right answer to regain some control over what was going on.

Though some of that was limited to macOS which seems to get a lot less attention from Apple than iOS, or because you're naturally building more complex layouts on macOS. But it always makes me appreciate how much better the kit is for building web frontends.

Most of the layouts I've built on macOS are actually simpler than their iOS counterparts because the mode of interaction is so different. Getting data onto the screen in a somewhat natural way is usually less of a contorted process because one doesn't need to deal with a software keyboard, a narrow viewport, lots of scrolling, etc.

The problem with SwiftUI on macOS in my opinion is that it's just not well-suited to the types of layouts common on desktop and especially macOS. It's best at uniform grids and lists which is more of a mobile thing. On macOS you want things like visually balanced whitespace, optical centering of labels+controls in forms, etc which are often rather arbitrary and exactly the thing that SwiftUI is worst at.

I've heard about SwiftUI just some months ago, and was initially excited about the demonstration in WWDC, so I started to pay more attention to it. Now I've been reading comments on how it doesn't handle well more complex UIs, but haven't really read anything in depth. Can you recommend any resources on that?

I use it full time, I’d say if you’re targeting iOS17+ you’re probably good. On macOS it’s completely busted still and I wouldn’t bother with it. The future of mac apps looks even bleaker than it did before.

All this magic being baked into the language (as opposed to the libraries/ecosystem) is why I abandoned being a native app developer professionally

Eh, I'm not too bothered by it. SwiftUI has its issues but I've put the result builder feature powering it to use for things vastly more simple than SwiftUI, for which it works very well. It's a net positive overall and I prefer it to having to rope in libraries for every little thing.

SwiftUI errors in general are mostly unhelpful.

It will go so far as to suggest a change in a thing only for the developer to find out the cause was completely unrelated or even in a model in a different file.

Helpful error messages for SwiftUI would go a long way

Admitting SwiftUI to have been a mistake and reinvesting back into AppKit and UIKit would go a long way.

In what other industry does anyone use text to create visual layouts? We still do drag and drop to design the layouts anyway, followed by re-creating the drag and drop version... using text...

It's all quite maddening if you try and make sense of it.

iOS and macOS had a visual editor forever. Interface Builder was a really interesting take on visual layout, instantiating real objects in the interface and serializing them into nib / xib / storyboard files ready for use in your app.

Most developers I know in the ecosystem tried and tried to like the visual editor, but ended up falling back to code. Why? Source code is pretty great. It’s easy to read, write, share, diff, and organize.

SwiftUI has, again, a very modern and interesting take on visual editing. The code is the truth, but there’s a rich, realtime preview canvas that makes rountripping possible. For reasons, it’s unfortunately all but unusable for a lot of folks with complex Xcode projects, but it’s a very good idea.

In summary: Visual layout editors and text are both pretty great. The devil’s in the details.

I find that Interface Builder, while not great for editing XIBs on iOS and storyboards on either platform (it's slow and buggy in those cases), is actually still fairly pleasant when working on Mac XIBs. My go-to is pure code UIKit on iOS, but I still reach for XIBs frequently for Mac stuff.

If IB's performance and stability issues could be fixed, I think its biggest problem is the near-unintelligible spaghetti XML that it generates for XIBs and storyboards, which is a huge pain for VCS and frequently cause of merge conflicts (which must be manually corrected). If they just cleaned up the XML output or switched to something more friendly to manual editing that'd help a lot.

Android Studio (before Jetpack Compose) split the difference and offered easily editable/readable XML with textual autocomplete AND a visual editor. I much preferred that after having spent years working in Xcode's Interface Builder.

xibs and storyboards were also XML but IB would insert attributes that had no visual impact, move lines of XML around simply upon opening the file, or randomly change x/y values of the viewport upon opening the file, or update float values to use 15 decimal places instead of 2, and so on. Apple's insistence on making the visual editor have priority over text led to a worse developer experience as teams grew.

I think a text-based, declarative rendering API is the right choice. This approach has been vindicated on the web.

But the actual implementation of SwiftUI is terrible. Long compilation times, cryptic compiler error messages, bad performance, and a baked-in two-way binding observable state API that's great for code snippets and WWDC talks but makes building a coherent state model in a real app very difficult add up to a big mess.

You just gave me flashbacks to 1.0 in 2019

In my case, Metrowerks CodeWarrior student edition in the late 90s, when I was going though "C for Dummies" in highschool.

Miss a semicolon, every line after but not including the one with the error.

ResEdit was better in the 90s than SwiftUI was in Xcode last year. Hoping to find that standard will be re-achieved when I install the update…

> the compiler is asking me to help it out

Yeah, this sucks, but it's also mind-boggling. The SwiftUI body result builder returns "some View" which means the compiler has to infer the specific type that the function produces, as a complex combination of whatever different if/then and while loops, along with their transitive function applications and closure contexts (where the type inference can be outside-in instead of inside-out).

Then layer in in the @Observation macro magic for observing data types and re-building views when data changes, Swift Data pulling with fully typed predicates from a data store automatically replicated across devices....

It's like rocket thrusters from every angle, and pretty easy to start tumbling off the happy path.

Saw this on a video-stream while the poor coder was struggling..you could see his BP rising.