Organizar las vistas en una app iOS con SwiftUI no se trata solo de pintar pantallas bonitas, sino de separar responsabilidades para que cada archivo cumpla una función clara. Al aplicar el patrón MVVM (Model-View-ViewModel), la capa visual se convierte en la representación pura de los datos, y aquí vas a ver cómo construir esa capa para una app de tareas (todos) en Xcode.

¿Cómo se organiza la carpeta Views en un proyecto SwiftUI?

Dentro de Xcode, la estructura del proyecto separa cada responsabilidad en directorios distintos. Tienes uno para Models, otro para vistas comunes y uno nuevo llamado Views que creas con clic derecho sobre el proyecto.

La regla práctica es sencilla: tendrás tantos subdirectorios dentro de Views como pantallas principales tenga tu aplicación. Para esta app de tareas son tres:

• TodoList: la pantalla principal que muestra todas las tareas pendientes.
• TodoArchived: la pantalla con las tareas archivadas.
• TodoAdd: la pantalla para agregar una nueva tarea.

Dentro de cada directorio puedes segmentar la pantalla en varios archivos. Así evitas que un solo archivo cargue con toda la responsabilidad visual y mantienes el código legible.

¿Por qué crear un directorio por pantalla en SwiftUI? Porque te permite dividir una vista compleja en componentes más pequeños sin saturar un único archivo, y facilita encontrar y mantener cada parte de la interfaz.

¿Cómo se construye la vista TodoList con SwiftUI?

La pantalla principal arranca importando SwiftUI, el framework que te da todas las herramientas para construir la interfaz de usuario. Después declaras una estructura pública llamada TodoList que hereda de View, lo que indica que ese archivo es una vista.

Dentro defines unas columnas que sirven para crear grillas. Las tareas no se apilan en una lista plana: se acomodan en una matriz para que la pantalla se vea más amigable y aproveche mejor el espacio.

En el parámetro body, que contiene todo el cuerpo del diseño, se usan estos elementos clave:

• ZStack: permite colocar vistas sobrepuestas, una encima de otra.
• ScrollView: habilita el deslizamiento vertical para mostrar N tareas sin límite de pantalla.
• Atributos de ancho y alto para controlar el tamaño de cada elemento.
• Title: el título asignado a la pantalla, en este caso "Todos".
• Toolbar: la barra superior con dos botones, uno con ícono de basurero (lleva a archivados) y otro con signo más (abre la pantalla para agregar tarea).

Esa toolbar es la que conecta la pantalla principal con las otras dos vistas de la app, así que actúa como el punto de navegación central.

¿Cómo se diseña la vista para agregar una nueva tarea?

La pantalla TodoAddView también es una estructura pública que hereda de View. Su cuerpo se construye con un VStack, que alinea los elementos de manera vertical, uno debajo del otro.

Aquí encuentras espacios vacíos a propósito. Faltan piezas que conectan con el modelo y el view model, así que el código se completa en pasos posteriores. Por ahora, la vista incluye un botón vacío y un botón llamado Guardar en la parte inferior.

Un detalle interesante es el uso de vistas comunes como TodoSheets. En lugar de mostrar AddView como pantalla completa, esta utilidad la transforma en una hoja modal (sheet) que aparece desde abajo. El resultado es una interfaz más llamativa y menos invasiva para el usuario.

¿Qué es un VStack en SwiftUI? Es un contenedor que organiza sus elementos hijos en una columna vertical. Cada vista se coloca debajo de la anterior, ideal para formularios y listas simples.

¿Cómo manejar la vista de tareas archivadas?

La vista TodoArchived arranca con un ScrollView vacío. La idea es ir agregando los elementos necesarios para verificar si en el almacenamiento local existen o no notas archivadas.

Aquí entra una validación importante basada en el estado de cada tarea:

• Si la tarea tiene estado archivada, se muestra en esta lista.
• Si la tarea no está archivada, se omite.
• Si no existen notas archivadas, conviene mostrar una vista de estado vacío que indique que no hay archivos disponibles.

Y aquí viene lo interesante: estas validaciones no se hacen accediendo directamente al modelo. Se acceden a través del view model, porque MVVM existe justamente para separar responsabilidades. La vista no decide la lógica de filtrado; solo muestra lo que el view model le entrega.

¿Por qué la vista no debe acceder directamente al modelo en MVVM?

El patrón MVVM divide tu app en tres capas con roles muy claros. El modelo guarda y estructura los datos (en este caso con Core Data), la vista solo se encarga de mostrar la interfaz, y el view model es el intermediario que prepara los datos del modelo para que la vista los consuma.

Si la vista accediera al modelo directamente, mezclarías lógica de negocio con lógica visual. Eso rompe la separación de responsabilidades y hace tu código más difícil de mantener y probar.

Con esto ya tienes dos de las tres piezas clave de MVVM construidas: el modelo con Core Data y la estructura inicial de las vistas. Falta el código que las conecta, y ese puente es justamente el view model. ¿Qué pantalla de tu app crees que se beneficiaría más al separarla en subvistas? Cuéntalo en los comentarios.