How to properly re-architecture for correct ARC (similar to VIPER)?

Question

Swift

A few explanations on the
Assistent scheme (something similar to an interactor), but only looking "into the world". It loosely holds the Presenter module, and also has features that are visible to the entire application. Something like "presentOnViewController" and "isCanShowNow". Conceptual examples.
Presenter , as I indicated above, holds a strong Assistant link (why I will explain below) and its function is clear - it configures the ViewController and processes events from it.
VC - controller, holds a strong link presenter
And now how the chain of interaction looks like: the user presses a button on the VC - the handler is in the Presenter. From it there is already an appeal to the Assistant, which gives an answer. Based on the response, the presenter updates the controller. Everything is great.
But this whole scheme is a module. And in fact when I create it - I create a variable. For example, SimpleAssistant.
Next, I configure the fields, if necessary, and call "presentOnViewController" (of course, it is hidden by the protocol, the Assistant does not know which presenter, it just has a set of functions looking into the application). The controller presents and everything is super.
But there is a catch. As soon as I create an Assistant object, the controller will die immediately. It has not yet been presented and no one is holding it. Of course, you can make the assistant hold the presenter, and the presenter hold the controller, but there is a moment - as soon as the assistant's visibility area ends (for example, I initialized him in the selector) - the assistant and the presenter will die. The controller will live because it is on the stack. But it will not work correctly without a presenter and an assistant.
I guess the problem is in the architecture, how to reorganize the links correctly?

Answer 1

Remove stack?
Make an Assistant that will hold/create other assistants/model_viewcontrollers?