VIPER is not clean, not even close

VIPER is not clean, it’s a boilerplate mess

Ahh shit, here we go again

The year is 2020, and VIPER continues to spread misinformation on how it is supposed to solve massive view controller problem.

Graphite on the roof

This article summarizes the pros and cons of VIPER:

VIPER mentality
  1. At what cost
  2. Prove it
  3. How is it better than alternatives, or SDK?
  1. It has 100 roles, which means creating 100 extra objects manually for each view.
  2. No mercy
  3. COBRA Kai never dies!

How does an VIPER interactor explode?

When you create interactor (Controller in MVC sense) outside of SDK view controller hierarchy, incorporate it with presenter which inherits some of worst problems of MVVM in iOS (no binding), and add a useless router on top of it.

Cost of lies

There’s one thing in common between MVVM, RxSwift, and VIPER.

  1. Move things to a external view model object
  2. Create binding via observables and observers from RxSwift.
  3. Depending on one’s ego, throw interactor, router, protocol, generics or other over-generalizations on top of it
  4. Publish tutorial on how it solves massive view controller problem.
  5. Never mention the fact that if you don’t do step 1, you can just use property observer for the same effect, omitting step 2–3.
  6. Any competent devs would choose function over object then use POP to refactor out functions to keep view controller compact.
  7. But step 6 is equivalent to following SDK, which is bad for selling tutorial. So we are back to step 1.
We no longer recognize Swift features

Take a grain of boron and sand

To answer this guy’s title question:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store