![Imagen de portada de [Arquitectura iOS #5] Por qué VIPER cayó en desuso (RIBs)](/assets/images/posts/ef088d05-20c3-46e5-95b6-d23a695099e9/1.jpg)
Pocos patrones de arquitectura iOS dividen tanto las opiniones como VIPER.
Algunos lo llaman «la respuesta para colaborar en equipos grandes»; otros, «el infierno del boilerplate». Varias apps de servicios grandes adoptaron VIPER o variantes y, años después, migraron a estructuras más ligeras.
Hoy resumiremos qué intentaba resolver VIPER y por qué su coste era tan alto.
VIPER tiene cinco piezas
VIPER divide una pantalla en cinco responsabilidades. El propio nombre proviene de sus iniciales.
- View: muestra la pantalla, incluido el controlador de vista. Solo «dibuja».
- Interactor: lógica de negocio. Obtiene datos y aplica reglas.
- Presenter: actúa entre View e Interactor. Prepara los datos para la pantalla.
- Entity: modelo de datos puro.
- Router (Wireframe): gestiona la navegación.
Divide en cuatro partes lo que hacía un solo controlador de vista en MVC (Model-View-Controller) y extrae la navegación en una pieza aparte (Router). Cada responsabilidad del Massive View Controller que vimos en la primera parte recibe su propio lugar.
La regla central es una relación de referencias estricta y casi unidireccional. View solo conoce Presenter; Presenter conoce Interactor y Router; Interactor solo toca Entity. Cada límite se define con un protocolo, así que cualquier pieza puede sustituirse por un mock.
¿Qué mejora?
Hay situaciones claras en las que esta estructura destaca.
Primero, permite elevar la cobertura de pruebas al máximo. Como cada límite es un protocolo, Interactor, Presenter y Router pueden probarse de forma aislada.
Segundo, facilita la división del trabajo en equipos grandes. Todas las pantallas tienen la misma estructura, lo que hace predecible la organización de archivos. Esa uniformidad ayuda de verdad cuando decenas de personas trabajan en el mismo código.
Tercero, encaja bien con la modularización por funcionalidades. Como cada pantalla es un conjunto autocontenido de cinco piezas, resulta fácil extraer módulos por funcionalidad. RIBs, creado por Uber e inspirado en VIPER, lleva esta idea al extremo: divide la app en un árbol por unidades de lógica de negocio, no por Views.
¿Por qué se fueron todos?
El problema es el coste.
El boilerplate es abrumador. Incluso una pantalla con un botón genera seis o siete archivos: View, Interactor, Presenter, Entity, Router y sus protocolos intermedios. La queja de que «cambiar el texto de una etiqueta requiere pasar por tres archivos» está más que justificada.
Incluso las pantallas sencillas deben cargar con el mismo peso. Una pantalla de ajustes estática y una pantalla de feed compleja reciben cinco piezas. El peso de la estructura no guarda proporción con la complejidad de la pantalla.
La curva de aprendizaje y el coste de incorporación también son considerables. A los recién llegados les lleva tiempo seguir el recorrido de los datos: View → Presenter → Interactor → Presenter → View.
El golpe definitivo fue la llegada de SwiftUI. VIPER nació de una preocupación de la era UIKit: retirar responsabilidades de los controladores de vista. En SwiftUI, View ya es ligero y la navegación funciona de otra forma, por lo que piezas como Router resultan extrañas. El problema de fondo cambió.
Entonces, ¿VIPER fracasó?
Es difícil verlo así. El legado de VIPER está integrado en las prácticas estándar actuales.
- Extraer la navegación a un objeto dedicado → consolidado como patrón Coordinator
- Separar la lógica de negocio de la presentación → consolidado como capas UseCase/Repository
- Definir los límites con protocolos → consolidado como inyección de dependencias y prácticas de pruebas
Cada vez menos equipos usan las cinco piezas de VIPER juntas, pero los problemas que resolvía cada pieza y sus soluciones sobrevivieron. Hoy es más habitual elegir solo las piezas necesarias.
Resumen
- VIPER divide una pantalla en cinco piezas —View, Interactor, Presenter, Entity y Router— y define sus límites mediante protocolos.
- La facilidad de prueba y la uniformidad en equipos grandes son ventajas, pero el coste de boilerplate es alto: seis o siete archivos por pantalla.
- Al cambiar el problema de fondo en la era de SwiftUI, menos equipos usan VIPER tal como era originalmente.
- Su legado sobrevive en prácticas estándar como Router→Coordinator e Interactor→UseCase.
En la próxima entrega trataremos la forma más extendida de ese legado: qué hacen realmente UseCase y Repository de la arquitectura limpia en iOS.
Lecturas recomendadas
- El patrón MVVM en iOS: por qué queda incompleto sin binding (ejemplos con Combine·Observation)
- El patrón MVC en iOS: la verdadera razón por la que aparecen Massive View Controllers
- [Arquitectura iOS #8] Guía para elegir arquitectura iOS según el tamaño del equipo, la vida útil de la app y la complejidad del estado