Why does the Router own the RIB rather than the Interactor?

From a memory perspective, the Router is the owner of the RIBs, in the sense that it keeps a strong reference to the Interactor. This choice feels counter-intuitive to me and I would love to know more about the motivations behind it.

The interactor decides and speak imperatively to the router. Talking imperatively to a property that is weakly retained is not something that people are used to imo. There's nothing fundamentally wrong with it but I think the learning curve would be slightly less steep if RIBs stuck to what people are used to, especially considering all other weakly-retained "listeners" in other parts of a RIB stick to this convention.

I read in the documentation that returning the Router is a way to add an extra layer to encourage Rx streams rather than imperative communication to a child RIB. It seems worse to talk to a router directly since it means by-passing a RIB altogether. Though maybe this is less tempting to developers?

Personally, I would rather imagine RIBs to attach/detach interactors, re-inforcing the fact that interactors are the core of a RIB in a business-logic-driven world. It would mean having the router return a tuple in RIB with a view: an interactor and a UIViewController. And maybe that's the actual main reason for this choice: avoid to rely on tuples?

The issue cites the RIBs documentation and the Router/Interactor ownership model; start by reading the relevant documentation on lifecycle and communication. A useful outcome is a settled rationale or explicit design decision about ownership and the proposed tuple, with any documentation change identified.