[iOS] How Uber create a viewable RIB based on UIView not UIViewController ?

[qhhonx]

As documentation mentioned that a RIB can be viewable or viewless, it is found that viewable RIB must be associated with UIViewController. However, I think it is not possible and most viewable RIB should be UIView-based as RIBs framework encouraging us to make reusable and micro components.

As the below image shown, are those viewable RIBs (Confirmation, Location Refinements, Menu) UIViewController based?

[dangthaison91]

My idea is that we can recursive to get parent viewcontroller from a UIView:

extension UIView {
    func findViewController() -> UIViewController? {
        if let nextResponder = self.next as? UIViewController {
            return nextResponder
        } else if let nextResponder = self.next as? UIView {
            return nextResponder.findViewController()
        } else {
            return nil
        }
    }
}

But not sure if actually does Uber team are having UIView with RIB instead of UIViewController.

[kovpas]

All viewable RIBs on the diagram above (Confirmation, Location Refinements, Menu) are UIViewController based.

[theangelperalta]

@qhhonx, Why would you like to use a UIView vs. UIViewController? A common misconception in iOS development is that UIViewController needs to represent a single "screen" in application; however, this is not the case. UIViewController can be composed of subsequent child UIViewControllers. These child UIViewControllers can represent something as small as a button. Hence, why it seems why these examples stick to using UIViewControllers instead of UIViews. What's the use case for just using a UIView?

[aurelienp]

Some thoughts about this topic:

• in a scenario of a complex collection-view cell (or rather its inner content view) built as a RIB, would you go as far as building a UIViewController for each cell, disregarding the perf overhead?
• it's somewhat counter-intuitive to have an architecture framework that is very generic and agnostic of the platform but that has a strong tie to UIViewController. I think I understand the why, the architecture pattern implementation of RIBs is fully agnostic of the platform but the architecture framework implementation is tied to the platform but it still makes me sad.
• by definition, a part of RIBs (the architecture pattern part) is meant to be a replacement of MVC. Still having a UIViewController in the middle feels redundant at best, or confusing. Confusing in the sense that people could be tempted to add business logic there because of strong habits from the past. Though I understand it's required in some case where we need compatibility with the platform, eg. UITabBarController, UINavigationController etc.
• the UI-driven-by-business-logic philosophy of RIBs seems to play very well with SwiftUI. Having to create a UIViewController wrapper just for the sake of making the view compatible with RIBs is a bit sad. I'm tempted to assume that SwiftUI should be a separate topic and that you will consider SwiftUI support more easily because it's possible to track things such as appearance for a SwiftUI view, which is not the case of a UIView.

Before diving into the details of the RIBs internals, I'd like to turn the question around and ask what is the strong reason for RIBS to force the usage of UIViewController? Is it because it needs to track things such as appearance, disappearance?