SwiftUI Defaults Considered Harmful

Edsger Dijkstra's original title was "A Case Against the Goto Statement". Niklaus Wirth was editor of the Communications of the ACM (Association for Computing Machinery) at the time and changed the title to the now infamous "Go To Statement Considered Harmful".

I don’t mind doing programmatic tweaking, but on my machine, at least, I don’t get very reliable previewing. I have to run the app to get an idea of how my tweaks are working (to be fair, IBE is similar, but the preview is somewhat more reliable).

I really want this to work. I’m glad to see KVO getting some love on iOS.

After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples on developer.apple.com were already outdated. I finally got something up and running, but _nothing_ in the semantics worked as expected. Getting a button to render nicely was insanely complex (which view should have the background color? font? trying different things didn't work at all). Oh and recompiling took a minimum of 30 seconds each time.

All this prompted me to finally give react-native a try. In under 15 minutes I had a working example. After making a change I saved the file, alt-tabbed to the simulator and the changes were already applied. And it works instantly on Android, I can try it out on my phone using expo without any hassle.

I just can't comprehend if and how Apple will catch up with that experience?

The author is confused about the whole approach to SwiftUI and spends a lot of words complaining about issues arising out of that confusion. E.g., SwiftUI doesn't use Swift's DSL capability to avoid commas. It uses it to have a declarative DSL integrated into Swift programs. You could argue about the entire approach, but instead the author complains about commas and ifs. The things about the ifs and other potential control flow constructs makes it clear that the author doesn't get what a declarative approach really means.

Likewise, the section about "wraps" where the author feels the SwiftUI API is inconsistent because stacks "wrap" and padding "wraps" so they should use the same syntax. But I think that's just a misunderstanding of the author's. "wrapping" isn't a fundamental concept of SwiftUI so there's no particular reason for the API to be organized around it. (I would say stacks arrange a list of views and padding pads a view. Also, bold() operates on Text and returns Text because Text holds styled text and bolded Text is still Text. padding operates on any View and returns some View. The types flow naturally from the problem domain, so that's good.)

Also the conclusion: "The solution…is to be dumb and explicit!" That's really asking for a completely different framework. It seems a little off to criticism SwiftUI for not being what it was never intended to be.

I think there is good criticism in here, though. SwiftUI introduces a LOT of patterns, concepts, many of which will not already be familiar to many developers. It's concise and reads pretty intuitively, but many developers won't get far before hitting a lot of new stuff... that means steep learning curves and confusion, like the author. I don't know if that makes it bad, but it's certainly anyone consider using it needs to be aware of.