My team just finished the Liquid Glass UI for PolyPlan. I’m really happy with the product output, but I have very weird, mixed feelings about SwiftUI.
@thai_d_v
- 11 Followers
- 98 Following
- 63 Posts
Concurrency and SwiftUI have been my identity. With the current state of SwiftUI, I feel like I’m in an identity crisis. My next move will probably be diving deeper into advanced UIKit.
The performance is terrible. I don’t need to prove that point since it’s already all over the internet.
The paradigm also makes it very hard to design APIs that construct sophisticated and dynamic layouts, at least for me.
Apple says SwiftUI is the future, but I’m not so sure. And even if it is, I’m not convinced that future will be bright.
In the FP world, they say: “If it compiles, it works (almost certainly).” But in SwiftUI, it’s more like: “It compiles, but I have no idea why it doesn’t work.”
Speaking of dynamics, Swift has a very powerful generics model. Not as powerful as Haskell or Scala, but still really good. It lets you write very expressive APIs. But SwiftUI’s API design feels arbitrary and unnatural to me in a lot of ways. One example is the positioning of view modifiers. Since most are defined in view extensions, you can put them almost anywhere in the view body, and then whether the code works or doesn’t depends on your luck.
In the Elm architecture, where the idea of “views are functions of state” comes from, you get language level support that guarantees you can’t perform arbitrary effects. Swift, on the other hand, is not a “truly functional” language. You can accidentally perform some effect inside a transaction, which leads to undefined behavior. Don’t get me wrong, I’m not saying being “truly functional” is inherently right or wrong. I’m talking about the dynamic between the language and the framework.
mattcomiImagining an Xcode autocomplete picker that lists SwiftUI modifiers according to their “impact” on the elements in the view hierarchy. Nearly every modifier modifies a View and returns a View but they often are intended for a specific family of controls. So if there’s a ScrollView in the hierarchy, it’ll surface things like contentMargins. If there’s a Button, you’ll get buttonStyle and buttonShape.
Steve Troughton-SmithThere was a point where I would recommend SwiftUI for new developers, but that feels hollow when I certainly wouldn't recommend it to myself if I were a new developer.
You are trading user experience for (supposed) developer experience upfront, and it's incredibly difficult to claw that back later.
If you want to build excellent platform-quality apps, your starting point shouldn't ever be SwiftUI. It's a tool in your toolbox, not *the* tool for everything
Timeless article by @davedelong . Incredible!
https://davedelong.com/blog/2018/07/25/conditional-compilation-in-swift-part-1/
Conditional Compilation, Part 1: Precise Feature Flags
When developing an app or a library, it’s pretty common that at least once in the course of development, you’ll need to conditionalize compilation of your code. Maybe you’ll be accounting for a bug in the operating system where things that don’t work quite the same on your device as they do on the simulator. Or perhaps you’ll want to simply exclude code from your simulator builds because the simulator simply doesn’t have that functionality (like invoking the camera).
Alex OzunMy talk from Swift Heroes 2024 has just been published. If you're interested in Noncopyable types, type-level programming, and State Machines, go check it out.
I had a lot of fun researching the feasibility of Typestate programming in #swiftlang, and I'm happy with how this talk turned out.
