,
7 tweets,
2 min read
Read on Twitter
My impressions of SwiftUI after 3 weeks:
1. It’s no more obvious than AppKit/UIKit.
The most immediate effect of this is that it’s hard to tell whether something is broken in the beta or if you’re doing it wrong.
e.g. How do you turn off animations when reloading a List?
1. It’s no more obvious than AppKit/UIKit.
The most immediate effect of this is that it’s hard to tell whether something is broken in the beta or if you’re doing it wrong.
e.g. How do you turn off animations when reloading a List?
2. The published documentation for SwiftUI is poorly structured.
The documentation tends to list all the methods from `View` first—making it hard to find the APIs that define the type.
e.g. The actual `Button` APIs are the *last* 5-10% of this page: developer.apple.com/documentation/…
The documentation tends to list all the methods from `View` first—making it hard to find the APIs that define the type.
e.g. The actual `Button` APIs are the *last* 5-10% of this page: developer.apple.com/documentation/…
3. SwiftUI is currently more capable for individual views.
Most WWDC demos focused on building 1-2 views. This seems much more doable because the containers and abilities you need are missing, incomplete, or buggy.
e.g. `HSplitView`/`NavigationView` have been pretty iffy so far
Most WWDC demos focused on building 1-2 views. This seems much more doable because the containers and abilities you need are missing, incomplete, or buggy.
e.g. `HSplitView`/`NavigationView` have been pretty iffy so far
4. SwiftUI is more viable on less capable platforms
UIs on macOS are more complex than UIs on iOS or watchOS, so more is required. That additional functionality seems to be mostly missing right now.
e.g. On macOS, a window with a SwiftUI root view defaults to a (0, 0) size.
UIs on macOS are more complex than UIs on iOS or watchOS, so more is required. That additional functionality seems to be mostly missing right now.
e.g. On macOS, a window with a SwiftUI root view defaults to a (0, 0) size.
5. The integration with non-SwiftUI views is very nice.
IMO Swift’s excellent integration with Obj-C has been key for quick adoption. SwiftUI does the same with AppKit/UIKit.
e.g. I wrapped `NSSearchField` in SwiftUI in ~60 lines of simple code. Hosting SwiftUI is even easier.
IMO Swift’s excellent integration with Obj-C has been key for quick adoption. SwiftUI does the same with AppKit/UIKit.
e.g. I wrapped `NSSearchField` in SwiftUI in ~60 lines of simple code. Hosting SwiftUI is even easier.
6. SwiftUI does not mean unidirectional data flow
SwiftUI relies heavily on two-way bindings. The reference semantics make this much more complex than React or Elm, but you do get some things “for free”.
e.g. `@ObjectBinding` is used heavily, but `@State` is “free”.
SwiftUI relies heavily on two-way bindings. The reference semantics make this much more complex than React or Elm, but you do get some things “for free”.
e.g. `@ObjectBinding` is used heavily, but `@State` is “free”.
There’s no question that SwiftUI has many advantages over AppKit/UIKit. I look forward to using it, and I hope the obvious issues are resolved before this fall!
