That could be because early on, SwiftUI was pretty rough. Compile errors were inscrutable and there were various gotchas. It's gotten a whole lot better, and at this point I'd say is mostly a pleasure to use.
It's unlike any other UI Framework I've used and at first I didn't like it. If you approach SwiftUI without doing things the way the framework expects you too it's going to be frustrating. Once I learned how SwiftUI wanted me to think about the UI I found it pleasant to use. The documentation has improved a lot too (as have the third party tutorials), although there are still some suprises that I've encountered.
There is at least one important feature that is missing that many desktop apps need so I can't unreservedly recommend it for that yet, but for mobile development it is very nice. I am much more productive with SwiftUI than anything else.
The ability to set the tab focus order if you have a large group of inputs (so that tab and shift-tab cycle through them in appropriate way). The last time I checked SwiftUI had no straightforward way of doing this.
It can be very buggy (even on iOS 15), especially when you start doing anything complicated. It’s also still relatively new compared to UIKit and AppKit, so it can be hard to tell if something is not working because you aren’t doing it right or if there is a legitimate bug.
It’s missing a lot of features that are currently in UIKit and the way that views are structs and it’s a declarative UI means it can be hard to add custom UI and work around missing features. You have to wait for Apple’s developers to implement things. In UIKit you can just start overriding things (even if you probably shouldn’t).
Also in my experience performance can be awful in ways you can’t work around or fix easily, if at all. e.g. The framework is supposed to diff and determine if things have changed, if two views are equivalent, etc. This can slower than just forcing the system to consider everything changed and nothing is equivalent so it should reload everything. This might be a bug, but sometimes this diffing can happen even when you change nothing. Ive gotten incredibly stuttery performance when scrolling. When I hook it up to the performance analyzer I see it’s trying to diff the whole screen multiple times every frame for static, scrolling content. But this only happens with finger scrolling. Programmatic scrolling (e.g. with the crown in the watch) doesn’t do this and is stutter free.
Finally, Xcode support is bad. It still gives inscrutable errors (that are usually just a misplaced parenthesis or brace) and the type inference system can peg up the CPU at 100% CPU (and then the system will throw up its hands that the type is too complicated to figure out.)
Prototyping in SwiftUI is so, so much faster than in UIKit though.
To add to the list:
Coming from the web and being used to having a ton of control how every thing looks I found that customizing elements sometimes have surprising limitations in SwiftUI. Also be wary of trying anything UX wise which is non-conformant with the official spec.
Also xcode in general is such a bizarre IDE compared to the IDEA products or even VSCode which I felt was limiting me severely, even after making quite some effort to adjust and learn shortcuts.
I also found that the screen/component preview was just so inconsistent, performance hungry and slow that I stopped using it pretty quickly. I want to like SwiftUI but it feels too rough around the edges for me so I guess I'll check back in a year.
I tried flutter after and it was SO much less painful, more/easier customizable and tooling felt heaps better.
tooling really matters and its the biggest issue with swiftui still...
its what killed ibdesignable and storyboard in the end (too slow, needs to compile the whole app before it can do anything, noisy hard-to-diff xml etc)
I've built some of the same sort of primitives, albeit with different syntax. Rui's `state` function will give you a state handle allowing you to mutate state similarly to how @State works in SwiftUI. rui also has a notion of bindings, just like SwiftUI, and even environment. This is all great for defining state that's local to a widget, which I've seen some other reactive/declarative libraries struggle with actually. Rui doesn't have an equivalent of @ObservedObject, and it's not clear to me that it needs one because state values can be accessed by reference.
I like SwiftUI, but somehow I still like UIKit and even AppKit a little more. Some things are still just slightly too broken in SwiftUI, for example navigation. In the WWDC talk when they introduced SwiftUI they said that we can let Apple do the work of making the UI just by listing what we need, but I don't trust Apple to do this yet.
You can go back and forth relatively easily. I think that even if most of your views are still NSViews/UIViews SwiftUI makes sense even just to hook them up. ViewControllers are an anti-pattern.
You should usually use a UIView instead of a view controller anyway (if you do UIKit programmatically, which is the only sane way to do it). Then it is easy enough. I have my own little layout library on top of AutoLayout, and at that point SwiftUI is nice to combine with UIViews.
Bindings might be better but that doesn't necessarily mean that ViewControllers are an anti-pattern. Is there a better way to do it in an non-declarative OOP way?
not the op but what i usually do is just write a plain-old-class with actions/outlets/delegate-methods and place those in the storyboard/xib
if you are programmatically doing it, then you can just init it directly or use some injection/indirection mechanism
you can use the responder chain to send messages up to the nearest view controller if you need to, and if you need some lifecycle awareness, you can always delegate those from the view controller in various ways (protocols, notifications etc)
testing is also easier since they are plain objects with a few methods on them (just fill in their outlets with mocks and you are ready)
Except for the part where components are locked to an iOS/macOS version. Still have to support iOS 13 ? Have fun basically doing everything with only VStacks.
Compose at least makes it only a library bump away.
> Compose at least makes it only a library bump away.
this to me is the most annoying thing with regard to swiftui and apple development in general... especially considering swiftui views are mostly wrapping uiviews....
Watch this space. Specifically I am writing up my ideas for a fusion of SwiftUI and Druid, inspired in large part by Taylor's work on rui. This work is conceptual at the moment, not a finished product, but I am hopeful it will be a better direction for UI in Rust.
Comments
I’ve been writing SwiftUI lately and it’s the most productive GUI toolkit out there.
Taylor Holliday of the Audulus fame is porting it to Rust
https://github.com/audulus/rui
Yours is the first positive comment I read on HN about SwiftUI.
That could be because early on, SwiftUI was pretty rough. Compile errors were inscrutable and there were various gotchas. It's gotten a whole lot better, and at this point I'd say is mostly a pleasure to use.
It's unlike any other UI Framework I've used and at first I didn't like it. If you approach SwiftUI without doing things the way the framework expects you too it's going to be frustrating. Once I learned how SwiftUI wanted me to think about the UI I found it pleasant to use. The documentation has improved a lot too (as have the third party tutorials), although there are still some suprises that I've encountered.
There is at least one important feature that is missing that many desktop apps need so I can't unreservedly recommend it for that yet, but for mobile development it is very nice. I am much more productive with SwiftUI than anything else.
What is that important feature?
The ability to set the tab focus order if you have a large group of inputs (so that tab and shift-tab cycle through them in appropriate way). The last time I checked SwiftUI had no straightforward way of doing this.
Strange. That's even part of the Apple design guidelines, if I remember correctly.
Why are people complaining? That it’s buggy or that it’s fundamentally flawed?
It can be very buggy (even on iOS 15), especially when you start doing anything complicated. It’s also still relatively new compared to UIKit and AppKit, so it can be hard to tell if something is not working because you aren’t doing it right or if there is a legitimate bug.
It’s missing a lot of features that are currently in UIKit and the way that views are structs and it’s a declarative UI means it can be hard to add custom UI and work around missing features. You have to wait for Apple’s developers to implement things. In UIKit you can just start overriding things (even if you probably shouldn’t).
Also in my experience performance can be awful in ways you can’t work around or fix easily, if at all. e.g. The framework is supposed to diff and determine if things have changed, if two views are equivalent, etc. This can slower than just forcing the system to consider everything changed and nothing is equivalent so it should reload everything. This might be a bug, but sometimes this diffing can happen even when you change nothing. Ive gotten incredibly stuttery performance when scrolling. When I hook it up to the performance analyzer I see it’s trying to diff the whole screen multiple times every frame for static, scrolling content. But this only happens with finger scrolling. Programmatic scrolling (e.g. with the crown in the watch) doesn’t do this and is stutter free.
Finally, Xcode support is bad. It still gives inscrutable errors (that are usually just a misplaced parenthesis or brace) and the type inference system can peg up the CPU at 100% CPU (and then the system will throw up its hands that the type is too complicated to figure out.)
Prototyping in SwiftUI is so, so much faster than in UIKit though.
To add to the list: Coming from the web and being used to having a ton of control how every thing looks I found that customizing elements sometimes have surprising limitations in SwiftUI. Also be wary of trying anything UX wise which is non-conformant with the official spec.
Also xcode in general is such a bizarre IDE compared to the IDEA products or even VSCode which I felt was limiting me severely, even after making quite some effort to adjust and learn shortcuts. I also found that the screen/component preview was just so inconsistent, performance hungry and slow that I stopped using it pretty quickly. I want to like SwiftUI but it feels too rough around the edges for me so I guess I'll check back in a year.
I tried flutter after and it was SO much less painful, more/easier customizable and tooling felt heaps better.
tooling really matters and its the biggest issue with swiftui still...
its what killed ibdesignable and storyboard in the end (too slow, needs to compile the whole app before it can do anything, noisy hard-to-diff xml etc)
I'm the author of rui, in case anyone has questions :)
How different is the state managementin SwiftUI compared to the state in rui?
I've built some of the same sort of primitives, albeit with different syntax. Rui's `state` function will give you a state handle allowing you to mutate state similarly to how @State works in SwiftUI. rui also has a notion of bindings, just like SwiftUI, and even environment. This is all great for defining state that's local to a widget, which I've seen some other reactive/declarative libraries struggle with actually. Rui doesn't have an equivalent of @ObservedObject, and it's not clear to me that it needs one because state values can be accessed by reference.
I like SwiftUI, but somehow I still like UIKit and even AppKit a little more. Some things are still just slightly too broken in SwiftUI, for example navigation. In the WWDC talk when they introduced SwiftUI they said that we can let Apple do the work of making the UI just by listing what we need, but I don't trust Apple to do this yet.
You can go back and forth relatively easily. I think that even if most of your views are still NSViews/UIViews SwiftUI makes sense even just to hook them up. ViewControllers are an anti-pattern.
You should usually use a UIView instead of a view controller anyway (if you do UIKit programmatically, which is the only sane way to do it). Then it is easy enough. I have my own little layout library on top of AutoLayout, and at that point SwiftUI is nice to combine with UIViews.
How are ViewController an anti-pattern? It depends how they're used, no?
And yeah it's easy to use a SwiftUI view in AppKit or UIKit using a UIHostingController or NSHostingController
A big part of what ViewControllers do is synching data. I think that bindings do a better job at this.
Bindings might be better but that doesn't necessarily mean that ViewControllers are an anti-pattern. Is there a better way to do it in an non-declarative OOP way?
not the op but what i usually do is just write a plain-old-class with actions/outlets/delegate-methods and place those in the storyboard/xib
if you are programmatically doing it, then you can just init it directly or use some injection/indirection mechanism
you can use the responder chain to send messages up to the nearest view controller if you need to, and if you need some lifecycle awareness, you can always delegate those from the view controller in various ways (protocols, notifications etc)
testing is also easier since they are plain objects with a few methods on them (just fill in their outlets with mocks and you are ready)
Except for the part where components are locked to an iOS/macOS version. Still have to support iOS 13 ? Have fun basically doing everything with only VStacks.
Compose at least makes it only a library bump away.
So I’m still not sold on SwiftUI, and I’m beginning to think I’m learning the wrong paradigms to “get it.”
What would you say are the core concepts that make it click for you? Do you have any resources to recommend?
Did you watch any WWDC videos? Also the objc.io book on the topic is decent.
The videos from PointFree [1] are also excellent.
[1]: https://pointfree.co
First time I see it, pretty nice framework. Rust needs more of those.
Watch this space. Specifically I am writing up my ideas for a fusion of SwiftUI and Druid, inspired in large part by Taylor's work on rui. This work is conceptual at the moment, not a finished product, but I am hopeful it will be a better direction for UI in Rust.