4 ms·

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 e

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.

rudedogg 4y ago
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.
- fingerlocks 4y ago
  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]. [0] https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md#referencing-the-enclosing-self-in-a-wrapper-type https://github.com/apple/swift-evolution/blob/main/proposals...
pixelrevision 4y ago
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.

rudedogg 4y ago

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.

fingerlocks 4y ago
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]. [0] https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md#referencing-the-enclosing-self-in-a-wrapper-type https://github.com/apple/swift-evolution/blob/main/proposals...

pixelrevision 4y ago

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.