Where should VIPER modules be initiated in UIKit project

Question

I have read a lot of articles in internet, where people explaining what each layer responsobility is, and that router or in some articles "constructor" should create whole VIPER module. But no one does not explain where to create them and how (most of them use class function that return view controller, but where I should use this return value?). In my case I have initial UITabBarViewController and my single suggestion is to call a class function in viewDidLoad, but again what I should do with this return value (some view controller). I totally confused and will be very appreciated for some help. Thanks in advance!

Answer 1

VIPER is best thought of as autonomous zones that run their own internal affairs behind each zone's façade. The begin & end of life of internal affairs (e.g., UIKit instances within V[iew] zone) is managed as side-effects of messaging through the V zone's façade. That message to the V zone's façade originates either

1. from R[outer] zone if the begin-life act is related to navigation (which is most likely). Specific to your question, one instance of UITabBarViewController versus another instance of UITabBarViewController would typically be a side effect of navigation originating in R zone, upon navigating to to a new screen from some prior screen.
2. from P[resenter] zone if the begin-life act is related to cascading ramification traversing P zone that originated from within one of the V, I, P, E, or R zones. For example, the back-end processing of an entity might cause a UI interaction change to be notified to the V zone's façade, which in turn runs the internal affairs within the V zone behind the V-zone façade, such as instantiating a UIKit object.

Specific to your narrower question of what instantiates UITabBarViewController and what retains the return value of viewDidLoad, that would be the V zone's façade as part of managing the internal affairs of object-instance lifetimes within V zone as a side-effect of the V-zone façade's awareness (via interzone messaging mostly from P zone and less often direct from R zone) of the current accumulated state of the app that implies the current accumulated state of the UI that V zone manages as its internal affairs.

It is best to keep in mind: what if I were to remove all of iOS for iPhone/iPad from V zone to instead, say, put in substantially different MacOS operations (or any other UI supported by your choice of language, which is most likely Swift or Objective-C)? If the V zone is designed/architected properly with all UI details behind V zone's façade and with all non-UI state-of-the-app stuff in all the I, P, E, and R zones, then the port from iPhone/iPad to MacOS would be rather easier due to the self-containment of V zone, due to changing only the guts within V zone behind V zone's façade.

This all raises the question of how should the façade be designed to present a well-thought-out isolation of V zone to the other I, P, E, and R zones. Generally, the E[ntities] zone contains parameters that appear within interzone messages between the zones' respective façades, so entities are usually fairly obvious data flowing in the app that has no direct representation in Apple frameworks, but rather has a reason to exist independent of the internals of the UI operations regarding Apple frameworks. Beyond the entities, the OO design of the façades of each zone (and most especially the hide-Apple-speak mission of V zone's façade) is 100% your choice other than there should not be one iota of Apple framework content in the V zone's façade presented interzone to I, P, E, and R zones. At a very minimum, V zone's façade could be one enormous class with one singleton instance with a gargantuan amount of methods/messages; there is some simplicity & beauty to such a monolithic façade. But modern OO taste would be to break up that monolith into broad app-centric (as opposed to Apple-framework-centric or even UI-operation-centric) topics that each have a singleton instance. The content of the V zone's façade should not speak (in topic or in message) of such brutal details as “pop up such-and-such dialog box” but rather “notify user of such-and-such” so that perhaps it is popping up a dialog box on iPad, updating a region of the larger screen on iPad, and something quite different on MacOS, all of which are internal affairs within V zone that the rest of the app('s zones) don't really care about which UI gizmo was enacted on various OSes/platforms.