I’m an ex gamedev with the misfortune of having to work with a legacy SwiftUI project. SwiftUI, and Jetpack Compose on Android, are basically react-style functional dom-diffing style renderers and have all the problems that come from that. What’s worse is that often the project has to be recompiled in order to preview changes with this functions-as-UI-components philosophy
The dom-diffing style makes me think of one of my beliefs about software. You have two styles.
An active style where where when state is updated side effects happen directly inside the same call graph.
And this passive disconnected spooky action at a distance where you update state and something else is supposed to/might execute side effects at some unspecified time in the future.
The first way there is no magic going on. The second way it's all magic. I try to avoid writing code the second way if at all possible.
The first style is the source of uncountable UI bugs. I have lost track of the number of times I’ve seen the developer forget to set a dirty bit to redraw the screen when some state changes. It’s the imperative vs. declarative model. Declarative may often be slower but it has other strengths.
Don't get me wrong. I totally understand that your way is why we don't see annoying rendering bugs anymore. We just put up with UI's that are slower than 25 year old UI's on machines that are a 100 times faster.
At least with web apps, that tends to be the “Redux” style more than the “React” style causing that. Basically, lazy state management (and I mean this pathologically rather than in terms of Haskell’s ‘lazy’). The laziness comes from the business side of things, squeezing more productivity out of engineers per dollar. The declarative style doesn’t slow down web apps very much, it’s rerendering every component any time a state changes anywhere that does.
On mobile it’s a trade off of rendering bugs with UI bugs. I’ve seen issues on older Android phones where Compose causes the text field to lose focus and flicker when typing if autocomplete is switched on. The workaround is to tell users to switch it off in the OS settings. And of course the latency issues are UX concerns all their own
I consider it basically impossible to take more than 1ms on the CPU to update+render an UI screen, even the most complex one.
As long as rendering is done on the GPU it should not be more than 2ms even on full-screen 4K.
The architecture of SwiftUI must be really weird to be slow/janky on a M1.