Arquitectar una app real: el plano completo de un producto

Arquitectar no es elegir un patrón. Es ordenar decisiones. Casi toda la literatura sobre arquitectura de apps discute qué elegir —MVVM o TCA, SwiftData o Core Data, CloudKit o servidor propio— y casi ninguna discute en qué orden elegirlo, que es donde se juega el resultado. Hay decisiones cuyo coste de cambio crece de forma explosiva con el tiempo y decisiones que puedes revertir un martes por la tarde; confundirlas es la patología más cara del oficio. Esta lección recorre el plano completo de un producto realista —una app de tareas compartidas con cuentas, datos locales, sincronización y widgets— pero el objeto de estudio no es la app: es la secuencia. Al final deberías poder mirar cualquier propuesta de producto y decir con confianza qué hay que cerrar en la primera semana y qué sería una insensatez decidir tan pronto.

Fijemos el producto para tener algo concreto sobre lo que razonar. Una app de listas compartidas: la persona crea tareas sin cuenta y sin conexión desde el primer segundo, puede opcionalmente iniciar sesión para tener sus datos en todos sus dispositivos, puede compartir una lista con otra persona, y quiere ver sus tareas de hoy en un widget y añadir alguna por voz. Es deliberadamente modesto y contiene, sin embargo, todos los problemas duros del oficio: identidad, offline primero, resolución de conflictos, límites de proceso y una superficie fuera de la app.

El orden correcto de las decisiones

La primera pregunta no es qué patrón usar, es cuál es el modelo de dominio y qué invariantes debe respetar. Una tarea pertenece a una lista; una lista tiene una persona propietaria y cero o más invitadas; una tarea completada conserva quién la completó y cuándo. Esas frases, escritas antes de abrir Xcode, deciden más sobre la app que cualquier framework, porque son las que sobrevivirán a las tres reescrituras de la capa de presentación que ese producto va a sufrir en cinco años. El dominio es la decisión más cara de revertir y por eso va primero.

La segunda es la topología de la verdad: dónde nace un dato, quién puede modificarlo y cómo se resuelve el desacuerdo. En nuestro producto la respuesta es local primero: la fuente de verdad de escritura es el dispositivo, el servidor es un replicador y la interfaz nunca espera a la red para confirmar una acción. Esta decisión también es casi irreversible, porque una app diseñada asumiendo que el servidor manda tiene la lógica de estados de carga esparcida por todas las vistas y convertirla a local primero es una reescritura, no una refactorización.

La tercera es la identidad y la cuenta, que suele decidirse tarde y debería decidirse tercera. Si la app funciona sin cuenta y la cuenta llega después, existe un momento de fusión —los datos anónimos del dispositivo se incorporan a una cuenta recién creada— que hay que diseñar explícitamente. Aplazar esa pregunta produce la clase de fallo que enfurece: alguien usa la app tres semanas, se registra y sus tareas desaparecen.

Solo después de esas tres viene el patrón de presentación, que es —y conviene decirlo sin ceremonia— la decisión más reversible de todas. Cambiar una pantalla de MV a MVVM es trabajo de una tarde por pantalla. Elegir mal el modelo de dominio es trabajo de un trimestre.

Las capas y la regla de dependencia

Con el dominio fijado, la estructura se sigue casi sola. Tres capas y una única regla: las dependencias apuntan siempre hacia el dominio. El dominio no importa nada del sistema; contiene tipos, invariantes y reglas puras que se pueden probar sin simulador. La capa de datos implementa los protocolos que el dominio declara. La presentación depende del dominio y jamás de la implementación concreta de datos.

// Dominio: puro, sin SwiftData, sin URLSession, sin SwiftUI.
struct Tarea: Identifiable, Sendable, Equatable {
    let id: UUID
    var titulo: String
    var completada: Bool
    var actualizadaEn: Date
    var listaID: UUID
}

protocol RepositorioTareas: Sendable {
    func tareas(de lista: UUID) async throws -> [Tarea]
    func guardar(_ tarea: Tarea) async throws
    func observarCambios(de lista: UUID) -> AsyncStream<[Tarea]>
}

// Datos: la implementacion vive en otro modulo y nadie la importa
// salvo el punto de composicion de la app.
actor RepositorioSwiftData: RepositorioTareas { /* ... */ }

Ese AsyncStream merece un comentario porque es la costura donde el nivel 15 se encuentra con el nivel 11: el repositorio no devuelve una foto, devuelve un flujo, y la vista se suscribe a él con .task. Así el plano de datos empuja hacia el plano de presentación sin que la presentación tenga que preguntar periódicamente, y el estado de la pantalla vuelve a ser lo que debe ser, una proyección.

La modularización del nivel 17 se vuelve entonces mecánica: un paquete para el dominio, uno por cada implementación de datos, uno por área funcional de la interfaz y uno de composición que es el único que conoce a todos. La regla de dependencia deja de ser una intención y pasa a ser algo que el compilador verifica, porque un módulo que no importa a otro sencillamente no puede llamarlo. Es la única forma conocida de que una frontera arquitectónica sobreviva a la presión de una fecha de entrega.

flowchart TD
UI[Modulos de interfaz] --> DOM[Dominio: tipos reglas protocolos]
DATA[Modulo de datos local] --> DOM
SYNC[Modulo de sincronizacion] --> DOM
WID[Extension de widget] --> DOM
APP[Modulo de composicion] --> UI
APP --> DATA
APP --> SYNC
style DOM fill:#a6e3a1,color:#11111b
style APP fill:#f9e2af,color:#11111b
style UI fill:#89b4fa,color:#11111b
style SYNC fill:#fab387,color:#11111b

La sincronización define la arquitectura

Aquí está el corazón duro del producto y la razón por la que la sincronización no puede añadirse al final: cambia el modelo de datos. Una app local necesita saber el estado actual de una tarea. Una app sincronizada necesita saber además cuándo cambió cada campo, qué dispositivo lo cambió, qué cambios están pendientes de subir y qué hacer cuando dos versiones se contradicen. Eso no es una capa que se apoya encima: son columnas nuevas, invariantes nuevos y un ciclo de vida nuevo para cada registro.

El diseño que funciona en la inmensa mayoría de productos de esta escala es el de cola de operaciones locales. La interfaz nunca escribe en la red: escribe en el almacén local y encola una operación. Un componente separado drena esa cola cuando hay conexión, con reintentos y retroceso exponencial. La reconciliación se resuelve con una regla escrita —último cambio gana por campo, con marca de tiempo del servidor para evitar relojes mentirosos— y los casos que esa regla no cubre se elevan a la persona usuaria en lugar de resolverse en silencio.

// La operacion es un dato, no una llamada. Se persiste, se reintenta,
// se inspecciona y se prueba sin red.
enum OperacionPendiente: Codable, Sendable {
    case crear(Tarea)
    case actualizarTitulo(id: UUID, titulo: String, en: Date)
    case completar(id: UUID, por: UUID, en: Date)
    case borrar(id: UUID, en: Date)
}

protocol ColaDeSincronizacion: Sendable {
    func encolar(_ operacion: OperacionPendiente) async
    func drenar() async          // idempotente y cancelable
}

Modelar las operaciones como datos tiene tres consecuencias que compensan de sobra su coste. La primera es que el borrado deja de ser destructivo: una eliminación es una operación con marca de tiempo, no la ausencia de una fila, porque de otro modo un dispositivo desconectado resucitaría lo borrado al reconectar. La segunda es que la app se vuelve probable sin red: se encolan operaciones, se drena contra un doble de prueba y se afirma sobre el resultado. Y la tercera es que la interfaz obtiene gratis su estado de sincronización —hay operaciones pendientes o no— sin que ninguna vista sepa nada de la red.

El plan de ejecución por fases

Un plano sin secuencia de construcción es un dibujo. Las fases que siguen tienen una propiedad deliberada: cada una termina en algo publicable y cada una verifica una hipótesis distinta del plano, de modo que si el plano está equivocado te enteras pronto y no en el mes ocho.

La fase uno es la app local completa, sin cuenta y sin red: dominio, repositorio local, las pantallas principales y las pruebas del dominio. Verifica que el modelo aguanta el uso real. La fase dos añade cuenta y sincronización con la cola de operaciones, incluida la fusión de datos anónimos al registrarse; verifica la hipótesis más cara del producto. La fase tres añade compartir listas, que es donde aparecen los permisos entre personas y los conflictos verdaderos. La fase cuatro extiende la app fuera de sí misma —widget y App Intents— y verifica que las fronteras de módulos eran reales, porque una extensión con presupuesto de memoria estrecho no puede arrastrar media app para pintar tres tareas. La fase cinco es endurecimiento: accesibilidad auditada, rendimiento medido con Instruments, observabilidad y el ciclo de publicación automatizado.