5 ms·

I've been probably jumping the gun on using SwiftUI in my app. It shows some promise conceptually, but I've encountered some severe pain points. - UI that is m

I've been probably jumping the gun on using SwiftUI in my app. It shows some promise conceptually, but I've encountered some severe pain points. - UI that is more stateful (like text fields, which have a selection range, etc.) aren't well supported. Say you want a button to insert text at the insertion point in a text field. You'll need to drop down to UIKit/AppKit for that. - Slow compile times due to the static typing of the view hierarchy. - Error messages that have little to do with where the problem is (you learn to read the tea leaves). - Gotchas e.g. a view can't have more than 10 children, and the error has little to do with that. - Declarative syntax is confusing, adds complexity to the language, and makes the error messages even worse. I still haven't figured out when I can and can't use normal syntax. - Poor performance for simple UIs. It's all built on top of AppKit/UIKit and chooses very heavy weight widgets for things like lists. You have to be careful about what gets regenerated, which is funny for displaying ~100 simple things on a screen. One of the biggest positives though is to finally be rid of autolayout, which was just utterly awful.

NobodyNada 7y ago
- Bugs. There’s so many weird bugs in SwiftUI, and the framework is so opaque and poorly-documented that it takes hours of trial and error to find an ugly workaround. That being said, hopefully these issues will get better with time. Swift 5.2 includes a new diagnostics architecture [0] that is supposed to greatly improve SwiftUI error messages. The 10-subviews limitation will be removed once we have variadic generics; a Swift Evolution proposal is currently being drafted [1] and is expected to land in Swift 6. [0]: https://swift.org/blog/new-diagnostic-arch-overview/ https://swift.org/blog/new-diagnostic-arch-overview/ [1]: https://github.com/technicated/swift-evolution/blob/variadic-generics/proposals/XXXX-variadic-generics.md https://github.com/technicated/swift-evolution/blob/variadic...
- tayistay 7y ago
  How could I forget the bugs? We've failed at doing some simple things (like tooltips on styled buttons on macOS). An Apple engineer [0] said the nested generics were used for SwiftUI because it makes diffing view hierarchies easy and makes identities stable, eliminating a class of bugs caused by changing view hierarchies during interactions or animations. But does potential dynamism actually cause problems in practice? (I haven't used other reactive UI toolkits.) It seems to me that most of the pain in using SwiftUI stems from the heavy reliance on generics. Hopefully it's worth it. [0]: https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/13 https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/...
hombre_fatal 7y ago
Also, your can't yet derive all of your views from state like you can in React or Elm because it doesn't expose all state to you. For example, <NavigationView> + <NavigationLink> doesn't update a History state object that you can control, push, or pop.
- dwaite 7y ago
  The view layer is meant to be dependent either on application state you provide, or its own internal state if you don't provide any. So for the NavigationLink example, there is an isActive parameter which takes a Binding<Bool>. If you set that value as true, the navigation will be made active. Likewise, you can read whether the navigation link is active by reading the bound parameter. Instead of pushing navigations onto a history object stack, you return a view that represents the nested navigations based on state. Bindings like 'isActive' are discretionary because the NavigationLink can provide the appropriate (if non-persisted) state if your application logic doesn't care.
- ollysb 7y ago
  As an Elm dev jumping into swift a couple of weeks ago I decided to just do the nav myself. I have an enum for Page and switch over that in the view. It seems far more obvious to use than the built in nav which doesn’t actually do an awful lot for you but takes away control(I did try the isActive approach but it seemed far more fiddly than using a Page enum).
favorited 7y ago
For error messages, they've apparently gotten much better in the Xcode 11.4 beta. There's a whole new diagnostics engine in Swift which has been designed to specifically solve the kind of error ambiguity that happens all the time with the insanely-nested generic SwiftUI types.
andrekandre 7y ago
> - Declarative syntax is confusing, adds complexity to the language, and makes the error messages even worse. I still haven't figured out when I can and can't use normal syntax. this they didnt have to go all the way to something like xml but right now its in the uncanny valley of DSLs imo; it should have been different enough that its quick to prototype and understand what's possible and whats not vs swift-like dsl we currently have

NobodyNada 7y ago

- Bugs. There’s so many weird bugs in SwiftUI, and the framework is so opaque and poorly-documented that it takes hours of trial and error to find an ugly workaround. That being said, hopefully these issues will get better with time. Swift 5.2 includes a new diagnostics architecture [0] that is supposed to greatly improve SwiftUI error messages. The 10-subviews limitation will be removed once we have variadic generics; a Swift Evolution proposal is currently being drafted [1] and is expected to land in Swift 6. [0]: https://swift.org/blog/new-diagnostic-arch-overview/ https://swift.org/blog/new-diagnostic-arch-overview/ [1]: https://github.com/technicated/swift-evolution/blob/variadic-generics/proposals/XXXX-variadic-generics.md https://github.com/technicated/swift-evolution/blob/variadic...

tayistay 7y ago
How could I forget the bugs? We've failed at doing some simple things (like tooltips on styled buttons on macOS). An Apple engineer [0] said the nested generics were used for SwiftUI because it makes diffing view hierarchies easy and makes identities stable, eliminating a class of bugs caused by changing view hierarchies during interactions or animations. But does potential dynamism actually cause problems in practice? (I haven't used other reactive UI toolkits.) It seems to me that most of the pain in using SwiftUI stems from the heavy reliance on generics. Hopefully it's worth it. [0]: https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/13 https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/...

hombre_fatal 7y ago

Also, your can't yet derive all of your views from state like you can in React or Elm because it doesn't expose all state to you. For example, <NavigationView> + <NavigationLink> doesn't update a History state object that you can control, push, or pop.

dwaite 7y ago
The view layer is meant to be dependent either on application state you provide, or its own internal state if you don't provide any. So for the NavigationLink example, there is an isActive parameter which takes a Binding<Bool>. If you set that value as true, the navigation will be made active. Likewise, you can read whether the navigation link is active by reading the bound parameter. Instead of pushing navigations onto a history object stack, you return a view that represents the nested navigations based on state. Bindings like 'isActive' are discretionary because the NavigationLink can provide the appropriate (if non-persisted) state if your application logic doesn't care.
ollysb 7y ago
As an Elm dev jumping into swift a couple of weeks ago I decided to just do the nav myself. I have an enum for Page and switch over that in the view. It seems far more obvious to use than the built in nav which doesn’t actually do an awful lot for you but takes away control(I did try the isActive approach but it seemed far more fiddly than using a Page enum).

favorited 7y ago

For error messages, they've apparently gotten much better in the Xcode 11.4 beta. There's a whole new diagnostics engine in Swift which has been designed to specifically solve the kind of error ambiguity that happens all the time with the insanely-nested generic SwiftUI types.

andrekandre 7y ago

> - Declarative syntax is confusing, adds complexity to the language, and makes the error messages even worse. I still haven't figured out when I can and can't use normal syntax. this they didnt have to go all the way to something like xml but right now its in the uncanny valley of DSLs imo; it should have been different enough that its quick to prototype and understand what's possible and whats not vs swift-like dsl we currently have