Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
swift-evolution
This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
-
Author here! Aside from Lunar (https://lunar.fyi/) all my apps over at https://lowtechguys.com/ are 100% SwiftUI.
In my extensive experience, this is the only major disadvantage I found: UIs with hundreds of stylized elements can be too slow
I suspect this happens especially because adding style to an element makes the graph deeper (e.g. Text(“”).shadow().colorInvert() means SwiftUI will add three function calls in the stack on each render pass)
But if that case does not apply to your UI, the advantages are massive.
For example my Volum [1] app works on iOS, iPadOS and macOS and because of SwiftUI it shares 95% of the code between platforms. That’s hard enough with other frameworks that I couldn’t even consider starting such a project before SwiftUI.
[1] https://lowtechguys.com/volum
We hit performance issues when writing a dataflow graph editor in SwiftUI [1]. We couldn't express the graph as Views and instead used a Canvas to draw everything. So, we had to do manual layout of everything, and manual event processing. This also precludes putting custom views for user-defined UI inside the modules. The performance problem had to do with evaluating the positions of all the wires between the modules using many GeometryReaders.
[1] https://github.com/audiokit/flow
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...
According to https://github.com/apple/swift/blob/6d2a3bbf9d518c2ff8c63731...
> The Swift language contains a number of features not part of the Hindley-Milner type system, including constrained polymorphic types and function overloading, which complicate the presentation and implementation somewhat. On the other hand, Swift limits the scope of type inference to a single expression or statement, for purely practical reasons: we expect that we can provide better performance and vastly better diagnostics when the problem is limited in scope.
However Hindley-Milner systems are generally linear in complexity whereas Swift's type system experiences combinatorial complexity explosions in the presence of overloads and operators and literals.