Control, you must learn control!

Why MVVM, VIPER, RIB all failed at Control

Intelligent beings are we, not these MVVM retards

This is what RIB says in their github:

Business logic drives the app, not the view tree. Unlike with MV*/VIPER, a RIB does not have to have a view. This means that the app hierarchy is driven by the business logic, not the view tree.

So you need more Control. This completes an arc from MVVM to VIPER to RIB. That arc is called “we need more control”.

MVVM uses ViewModel with states. But not all states are direct view-related states, it’s called business logic rather than view logic for a reason. MVVM devs can claim ViewModel is not Control when it contains all states that would otherwise reside in view controller with a straight face.

VIPER brings back explicit control, but splits it in multiple specific roles (Interactor, Presenter, Router). VIPER unfortunately got crushed by the sheer amount of overheads it introduces.

RIB for some reason decides to be crushed as well. The soy boys who call them iOS devs at Uber analyze the problem and decide that they can improve upon VIPER by introducing even more Control.

This is a story about how you think ViewModel can solve shit, and build around it, and find out that it doesn’t solve shit. In fact who gives a shit, make it simple and throw away, you need more control to contain the increasing complexity of business logic. You need so much control that you might as well have your app hierarchy built around it.

However this story does not have a happy ending. They all failed spectacularly miserably at Control.

Those who don’t write massive view controller have no need for these shit, and those who do are doomed to repeat it no matter what they use.

If you look at the propaganda of these design patterns / framework, they all claim they are solving massive view controller problem (MVCP).

Did it ever occur to you that, if having some extra objects to store shit is enough to solve MVCP, you wouldn’t have MVCP in the first place.

There are people that can refactor / arch the shit out of MVC.

Asking them how should be far easier than learning some bullshit RIB, which is based on VIPER, has mandatory RxSwift requirement, state management by inheritance hierarchy, and require heavy code-gen.

That, is why you fail.

Let’s first analyze why these shits fail.

MVVM is obvious, ViewModel is just controller that pretends to be harmless presenter. It’s MVC with extra steps. It gives you no guidelines on how you should structure Control. Again, if refactoring out control logic to some object can solve MVCP, you wouldn’t have MVCP in the first place. There’s nothing preventing you from writing massive view model either.

VIPER on the other hand, gives you guidelines, perhaps too many guidelines. Having clear-cut roles is nice, but it isn’t game-changing. Any half competent dev would already have a similar role assignment in their codes. By enforcing these roles and guidelines, the structure loses flexibility which hinders refactoring. When you have to repeat the same setup code, you are most likely doing it wrong, and need to stop to rethink your architecture.

VIPER devs think they can overcome it with, ironically, brute force code-gen.

Interactor, presenter, and router concepts are not earth-shattering, ground-breaking, mind-blowing constructs previously unheard-of and are supported by Swift and SDK. In fact, quite the opposite. It just gives names to common refactoring patterns, then awkwardly stitch them together and call it clean architecture. The legendary amount of boilerplate required should tell you how well it enjoys SDK and language support.

We haven’t even got to the worst part.

VIPER does not tell you how you should write an interactor!

What’s saving you from writing a massive interactor? You know presenter should be kept simple, and router deals with navigation. The rest goes to interactor. It’s a real possibility that you have complex logic in interactor.

So after all of that shit, nothing is solved, yet clean architecture is claimed. This is in consistent with the proud tradition of MVVM.

Finally, let’s look at RIB.

A control based hierarchy. It might be good?

Inheritance. No it can’t be good. I’ll tell you as a fact that one of the secrets of not having MVCP is to NOT allow inheritance of view controller.

It of course claims to be scalable, clean, solving MVCP … etc, as the tradition.

Not only does it NOT have support of Swift and SDK (from sheer amount of boilerplate), it straight up copy-paste from Java, thus suppressing Swift features.

It even has the audacity to have mandatory dependency on RxSwift, so RIB isn’t even self contained.

And the worst of all, it still does not prevent you from writing a massive interactor.

I have to give props to soy boys at Uber. They nailed it. Everything in RIB is designed wrong.

For they are literal shits.

If anything, SwiftUI should give you an insight on how things can be done with language features and SDK support (such as binding).

I’ll leave hints as to how you should do Control for now, because I have to go to sleep now.

POP, no extra objects, property observer.

Have you heard the tragedies of RIB the unwise?

These are not the stories shity developers would tell you…

Casual iOS developer