3 ms·

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.

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.

adamnemecek 5y ago
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.
- bowsamic 5y ago
  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
  - adamnemecek 5y ago
    A big part of what ViewControllers do is synching data. I think that bindings do a better job at this.
    - bowsamic 5y ago
      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?
      - andrekandre 5y ago
        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)
- auggierose 5y ago
  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.

adamnemecek 5y ago

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.

bowsamic 5y ago
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
- adamnemecek 5y ago
  A big part of what ViewControllers do is synching data. I think that bindings do a better job at this.
  - bowsamic 5y ago
    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?
    - andrekandre 5y ago
      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)
auggierose 5y ago
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.