Estructurar un proyecto iOS con Clean Architecture te permite separar responsabilidades en capas claras: Data, Domain y Presentation. Este enfoque facilita escalar tu app, integrar testing e inyección de dependencias, y mantener el código ordenado conforme crece.

Vamos a montar la estructura usando como caso práctico el consumo de la API de Movie DB desde Xcode, para listar películas populares y su detalle. Lo importante no es la app en sí, sino entender por qué creas cada carpeta y qué vive dentro.

¿Qué capas necesita un proyecto con Clean Architecture en iOS?

La propuesta se apoya en tres capas principales que conviven dentro del proyecto Xcode. Cada una resuelve una preocupación distinta y se comunica con las demás siguiendo límites claros.

• Data: contiene modelos, conexión de red y repositorios.
• Domain: alberga los casos de uso (use cases) que expresan la lógica de negocio.
• Presentation: agrupa Views y View Models, la parte visible de la app.

¿Qué es Clean Architecture en iOS? Es un enfoque para organizar el código en capas con responsabilidades únicas, de modo que la lógica de negocio quede aislada de la UI y de las fuentes de datos.

¿Cómo creo los directorios base en Xcode?

Dentro del IDE Xcode, haces clic derecho sobre el proyecto y eliges New Folder. Creas tres carpetas al mismo nivel: Data, Domain y Presentation. Con eso ya tienes el esqueleto que separa responsabilidades antes de escribir una sola línea de código.

Este paso parece simple, pero marca el rumbo. Cada archivo que sumes después tendrá un lugar lógico donde vivir.

¿Qué va dentro de la capa Data en una app que consume una API?

La capa Data concentra todo lo relacionado con el origen y transformación de la información. Como vas a consumir Movie DB, necesitas decodificar el JSON entrante y convertirlo en objetos Swift utilizables.

Dentro de Data se crean tres subdirectorios:

• Models: define las estructuras Swift que representan los datos que llegan desde la API.
• Network: maneja la comunicación HTTP con el servicio externo.
• Repositories: implementa el acceso a distintas fuentes, como la API remota y la caché local.

Esta división te deja preparado para que mañana puedas cambiar la fuente de datos, sumar caché o reemplazar el cliente de red sin tocar la lógica de negocio.

¿Por qué separar Network y Repositories si ambos traen datos?

Porque cumplen roles distintos. Network sabe hablar HTTP y entiende endpoints, headers y respuestas. Repositories abstrae de dónde vienen los datos y le entrega al dominio una interfaz limpia, sin importar si llegaron de la API, de caché o de una base local.

¿Para qué sirven Domain y Presentation en Clean Architecture?

La capa Domain contiene un directorio llamado UseCases. Cada caso de uso representa una acción concreta del negocio, por ejemplo, obtener la lista de películas populares o consultar el detalle de una.

La capa Presentation tiene dos carpetas: Views y ViewModels. Y aquí viene un detalle interesante: MVVM vive dentro de Clean Architecture. La parte de presentación de MVVM se queda en Presentation, mientras que los modelos viven en Data. No son enfoques opuestos, se complementan.

¿MVVM y Clean Architecture son lo mismo? No. MVVM se enfoca en la capa de presentación con Views y ViewModels, mientras que Clean Architecture organiza toda la app en capas. MVVM puede ser una pieza dentro de Clean Architecture.

¿Cuándo cambia esta estructura de carpetas?

Este enfoque aplica bien para una app que consume servicios en la nube. Si tu app es puramente local, probablemente no necesites la carpeta Network, pero sí podrías sumar otros directorios para persistencia local. La estructura responde al tipo de proyecto, no es una receta única.

¿Por qué conviene separar responsabilidades en capas?

La razón principal viene de los principios SOLID, en concreto del principio de separación de responsabilidades. Cuando cada carpeta tiene una única razón para existir, tu proyecto se vuelve más manejable.

Los beneficios concretos son:

• Escalabilidad: agregar funcionalidades nuevas sin romper lo existente.
• Mantenimiento: aplicar cambios, mejoras y actualizaciones con menos riesgo.
• Inyección de dependencias: reemplazar implementaciones sin reescribir la lógica.
• Testing: probar cada capa de forma aislada.

Si piensas en tu proyecto a seis meses o un año, esta inversión inicial en estructura te ahorra horas de refactor y bugs difíciles de rastrear.

¿Cómo organizas tú tus proyectos iOS hoy? Cuéntame en los comentarios qué enfoque sigues y si ya aplicas alguna variante de Clean Architecture.