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 judgement on SwiftUI for now though.
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.
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.
It makes the easy things easier. A common problem for these sorts of tools. It is help with the hard things that we need.
Edit - I have experience with SwiftUI not React.
React Native doesn't seem to have any degree of simplification vis-a-vis regular Android Views for example.
On the web - that's a different story entirely, but when doing strict comparison I just don't really buy it for mobile apps.
The amount of code is similar, but with React you have to deal with extra layers of abstraction, and some things are obfuscated by the framework. No performance gain and often a performance lost.
Yes, it's faster to write. Is it easier to maintain? Doubtful. Especially when you inevitably run into issues that your whole UI re-renders a couple of hundred of times a second, and you have to go in and butcher everything with useMemos, caching etc.
On the web frameworks like Solid.js are exploring these fine-grained reactivity approaches to actually re-render only what's needed, and not huge chunks of UI