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)
