Construir una app en iOS que funcione no es difícil.
El verdadero reto aparece después: cuando esa app crece.
Empiezan a surgir problemas que no estaban en el diseño inicial:
- ViewModels demasiado grandes
- Lógica duplicada
- Navegación acoplada
- Dificultad para probar código
Y en ese punto, MVVM que parecía una buena decisión comienza a romperse.
Este artículo no trata de explicar qué es MVVM.
Trata de entender por qué falla en proyectos reales y cómo evitarlo desde el inicio.
El problema no es MVVM
MVVM no está mal.
El problema es cómo lo implementamos.
En muchos proyectos, MVVM termina siendo esto:
- Views que dependen directamente del ViewModel
- ViewModels que contienen lógica de negocio, networking y estado
- navegación mezclada con lógica de presentación
Resultado:
Un sistema difícil de escalar.
Señales de que tu MVVM está mal aplicado
Si te identificas con esto, es momento de replantearlo:
- Tu ViewModel conoce demasiadas cosas
- Haces networking directamente desde el ViewModel
- La navegación está dentro del ViewModel
- No puedes testear fácilmente
Esto no es MVVM.
Es una mezcla de responsabilidades.
El enfoque correcto: separación real de responsabilidades
Para que MVVM funcione en proyectos reales, necesitas separar capas claramente.
1. View
Responsable únicamente de:
- renderizar UI
- reaccionar a cambios
No contiene lógica de negocio.
2. ViewModel
Responsable de:
- transformar datos para la vista
- manejar estado
No debería:
- hacer networking directamente
- contener lógica compleja
3. Capa de dominio
Aquí vive lo importante:
- casos de uso
- reglas de negocio
- lógica reutilizable
Esto es lo que normalmente se ignora.
Y por eso MVVM falla.
El problema de la navegación
Uno de los errores más comunes es este:
El ViewModel controla la navegación.
Esto genera acoplamiento inmediato.
La solución:
👉 usar un Coordinator Pattern
Esto permite:
- desacoplar la navegación
- mantener ViewModels limpios
- escalar flujos sin romper la arquitectura
Modularización desde el inicio
Otro error común:
“modularizamos después”
En proyectos reales, eso casi nunca sucede.
Desde el inicio, la estructura debería permitir crecer:
- Core (utilidades, base)
- Networking
- Features (módulos independientes)
- Design System
Esto evita que el proyecto se vuelva monolítico.
Decisión técnica
Decisión: usar MVVM + Coordinator + modularización desde el inicio
Alternativa: MVVM simple sin separación de capas
Razón: necesidad de escalar el proyecto sin aumentar complejidad
Lo que cambia cuando lo haces bien
Cuando MVVM está bien implementado:
- puedes agregar features sin romper otras
- el código es testeable
- la navegación es flexible
- la lógica está desacoplada
Y lo más importante:
Puedes pensar como arquitecto, no solo como implementador
MVVM no falla por sí mismo.
Falla cuando se usa como una plantilla rápida, sin considerar:
- separación de responsabilidades
- crecimiento del proyecto
- mantenibilidad
En proyectos reales, no necesitas más frameworks.
Necesitas mejores decisiones.