Other commenters have pointed to SwiftUI being declarative as a big part of this problem, but I take a more nuanced view: the problem is actually that SwiftUI is a complexity-hiding abstraction. Specifically it hides the complexity of when UI is refreshed and how it is refreshed.
This results in a situation where engineers who don’t have a clear understanding of how it works resorting to essentially guesswork to try and fix performance issues. Now, there are certainly folks who do have a deep understanding of how SwiftUI works but that group is likely small and the situation isn’t helped by middling documentation and SwiftUI being closed source.
An analogue to this can be seen in something like SQL, which is a (somewhat) declarative specification for queries that is also complexity-hiding. SQL, wielded by a novice, can be pretty slow (just one ill-advised join would likely do it), but would still “work”. The difference with SQL is that there is a plethora of literature about how to write it in a way that results in fast queries and many of the consumers of SQL are open source so enterprising engineers can dig down and figure out what a particular query is doing and why something is slow. We’ve also invested a ton of resources in creating engineers who can write good SQL.
I’m interested to see how SwiftUI progresses in these regards.
Unrelated addendum: The author should look at the drawingGroup API. This could significantly speed up the drawing of the month grids on refresh by caching the resulting rasterized view instead of repeatedly redrawing it.
I think Swift UI's more concrete problem is that it just doesn't have a sufficiently mature enough API with the right mix of low level primitives and higher abstractions.
Say whatever you want about modern web development, but I think React/JSX + HTML/CSS has proven you can use a declarative model to build complex user interfaces.
This could be taken to support my point. There is a MASSIVE amount of literature on the internet about how to do this, and it's reasonably straightforward to see what is happening with the DOM when you use these frameworks. Likewise, a novice developer can create something that causes scrolling to stutter or other performance problems pretty easily in this world.
Take on the other hand, some of SwiftUI's more advanced features, like PreferenceKey which are extremely under-documented (the generic sounding name doesn't help either). Of course folks are going to struggle to do more complex things.
I wonder how much the situation would be helped if the thing you searched for help allowed in-line SwiftUI examples, like you can do on the web. Playgrounds is kind of that thing but you aren't searching a repository of playgrounds for documentation.
I think the web developer's toolkit has benefitted from competition - every browser prioritizes supporting dev tools because that's the only way to get more sites to support your particular quirks. people building web frameworks competed for developers ruthlessly, because starting to learn a new framework is only a few search queries away, and a great deal of effort has been made to improve the overall developer experience.
I really like the SQL comparison. I'll remember that the next time I have to explain a non-iOS developer why a given piece of SwiftUI code is flaky or slow.
I feel like it is a mistake to bring what is effectively React to native development.
Browser-based web apps are basically punching above their weight class. Compared to the power of native UI's, the browser is broken. React understood this and created two innovations:
1. The Virtual DOM
2. The reactive UI
Now, I'm no expert, but Number 1 seems like a terrific idea; and Number 2 seems like it's needed in order to implement Number 1.
But, to my thinking, a reactive UI is a big problem of leaky abstractions, which is what I think you're saying.
To me, iOS/macOS UI development needed neither the baby nor the dirty bathwater. I feel like the whole thing is a mistake. As a programmer, I want control over updating the UI.
React is terrible at reactive[1] UIs. You have to do a lot of work to tell react what to not rerender. Of course things generally work if programmers aren't careful, but the UI gets slower and slower over time as more features are added and more repaints are done.
VDom is one of those arguable things, plenty of frameworks are faster than React w/o a vdom, and some frameworks are faster than React and also use a VDom.
[1] Arguably react is not even that reactive, you have to manually wire up everything yourself.
For the record, you do have fairly fine grained control over what updates when with SwiftUI. The issue is that this isn’t obvious to new developers, nor is it easy to understand what tools to use to fix issues once you understand what is happening.
I really wish apple would spend more time on their tooling. A lot of the new features like async/await and SwiftUI have way less visibility than what came before. A lot of this stuff makes the code compact and much easier to read but when things go south trying to use the inspectors they have often doesn’t get you very far.
There are a lot of foot guns, like ObservableObject and @Published causing views that reference the object (even if they don't use it in any way) to be re-rendered that cause issues. And even Apple can't figure it out, which can be seen from the Ventura System Settings performance.
SwiftUI is nice for small apps and demos. But as soon as you add persistence, or try and do anything advanced the complexity balloons and you need to understand it completely. I think SwiftUI is just a bad abstraction with a lot of accidental complexity. It makes drawing much easier/faster for developers but all the state management stuff has become very difficult.
Apple can figure it out- they implemented @Published such that it contains a reference to it's enclosing ObservableObject which invokes objectWillChange() very liberally. The fact that they wrote their settings UI poorly is a statement about the developer's assigned to build those components and/or the lack of QA involved.
I do agree that ObservableObject/@Published should have been designed to prevent unnecessary re-renders. It's actually quite easy, and I expect Apple will include this in the future: Add an extension to @Published when the value type is Equatable and only send objectWillChange() when newValue != oldValue. I do something like this in my apps to eliminate superfluous re-renders, but the implementation is non-trivial due to an undocumented feature in Swift [0].
I’m happy this worked for you. This in itself is an interesting anecdote about documentation quality. I knew this API existed but forgot the exact API and searches for “caching SwiftUI rasterized view” and similar queries did not return this API (which, for the record, isn’t exactly what it does…) . I eventually found it in a roundabout way but had I not been pretty sure it existed, I would probably have given up.
> This in itself is an interesting anecdote about documentation quality.
apple used to make these great deep-dive pdfs for new frameworks like core data, quartz (core graphics), even obj-c itself that explained many nuances and caveats of each subsystem/framework...
imho i think swiftui could use a good doc like that
Those were so awesome because they explained the whole system. The core graphics one was an absolute lifesaver when I started working with iOS. Apples UI a frameworks seemed way more complex than anything I’d ever worked with before but once I understood the layers they started to click. I don’t know what I would have done with a bunch of class guides with patchy comments.
Unrelated addendum: The author should look at the drawingGroup API. This could significantly speed up the drawing of the month grids on refresh by caching the resulting rasterized view instead of repeatedly redrawing it.