Pitches de Práctica

En Swift la gran distinción es entre tipos por valor y tipos por referencia. Los structs y enums son tipos por valor — cuando los asigna o los pasa, obtiene una copia, por lo que no hay estado mutable compartido de que preocuparse. Las clases son tipos por referencia: cada referencia apunta a la misma instancia, y están gestionadas por conteo de referencias automático.

Por defecto uso un struct, especialmente para modelos y vistas SwiftUI, porque la semántica de valor hace que el código sea más fácil de razonar. Recurro a una clase cuando genuinamente necesito identidad o comportamiento de referencia compartidos — por ejemplo un objeto modelo observable. Y el costo de copiar generalmente no es un problema porque las colecciones de Swift usan copy-on-write: solo copian realmente cuando muta una segunda referencia.

SwiftUI es declarativo: una vista es una función del estado, así que describo cómo debería verse la UI para el estado actual y el framework diff y actualiza la pantalla cuando ese estado cambia.

La habilidad es elegir la posesión correcta. @State es para el estado que una vista posee por sí misma. @Binding es una referencia bidireccional al estado poseído en otro lugar, para que un hijo pueda editar el valor de un padre. Para modelos compartidos uso el framework de Observación — una clase @Observable que mantengo con @State y vinculo con @Bindable. Y @Environment es la inyección de dependencias incorporada de SwiftUI para las cosas que se pasan hacia abajo en el árbol.

El principio debajo de todo esto es una única fuente de verdad: el estado vive en un lugar y fluye hacia abajo como bindings, por lo que la UI siempre es una reflexión consistente de ese estado.

El Swift moderno se construye sobre async/await y la concurrencia estructurada. Una función asíncrona puede suspender sin bloquear un hilo, por lo que escribo código asíncrono que se lee de arriba a abajo en lugar de anidar completion handlers. Para trabajo paralelo uso async let o un task group — los hijos se ejecutan concurrentemente y se esperan y cancelan juntos como una unidad.

Para el estado mutable compartido uso actors. Un actor serializa el acceso a su estado, por lo que los llamadores concurrentes no pueden competir — reemplaza locks y colas manuales. Y @MainActor garantiza que el código se ejecute en el hilo principal, donde mantengo la UI y los view models, en lugar de esparcir dispatch-to-main por todas partes.

Lo que une todo esto ahora es Swift 6, que verifica todo esto en tiempo de compilación: los tipos que cruzan límites de concurrencia deben ser Sendable, y el compilador aplica el aislamiento de actors. Así que una clase entera de carreras de datos se convierte en un error de compilación en lugar de un fallo en producción.

Empiezo por el equipo y el producto, no por un patrón favorito. Para la mayoría de las apps uso MVVM con el framework de Observación — vistas delgadas, un view model observable con la lógica y dependencias inyectadas detrás de protocolos para que todo sea testeable. Cuando una app se vuelve grande y con mucha lógica, me acerco a una arquitectura unidireccional como TCA, donde el estado vive en un lugar y los cambios fluyen a través de acciones, lo que hace que el comportamiento sea testeable de forma exhaustiva.

La decisión que más me importa a escala es la modularización. Divido la app en paquetes Swift locales — módulos de funcionalidad que dependen de paquetes compartidos Core, DesignSystem y Networking, nunca entre sí. Eso fuerza límites, paraleliza las compilaciones y permite que las funcionalidades se prueben y previsualicen de forma aislada.

Y trato la preparación para producción como parte de la arquitectura: un router para que la navegación sean solo datos, observabilidad y reporte de crashes, y feature flags con phased rollout para que pueda distribuir de forma segura y apagar algo sin un nuevo build.

Regla uno: mida antes de optimizar, porque el cuello de botella generalmente no está donde yo supondría. Recurro a Instruments — Time Profiler para CPU, Allocations y Leaks para memoria, el instrumento SwiftUI para conteo de view-body, y Hangs para bloqueos del hilo principal.

En SwiftUI la mayoría de las ganancias vienen de hacer menos: mantener el body de la vista ligero y puro, dar a las vistas identidad estable para que se reutilicen, usar stacks perezosos y List para contenido largo, y dejar que el framework de Observación re-renderice solo las vistas que leen una propiedad modificada. Para un feed de imágenes específicamente, reduzco la resolución fuera del hilo principal y cachéo miniaturas descodificadas — descodificar imágenes de resolución completa en una celda pequeña es la causa clásica de frames perdidos y picos de memoria.

Quiero que distribuir sea aburrido y repetible. En cada pull request, CI construye la app y ejecuta pruebas unitarias y de UI más lint. Cuando algo hace merge a main, CI archive, firma y carga un build de TestFlight automáticamente, autoincrementando el número de build.

Para un lanzamiento promuevo un build de TestFlight a App Store y uso un phased rollout, para que la actualización llegue a un porcentaje creciente de usuarios durante aproximadamente una semana — si las tasas de crash aumentan, puedo pausarlo. Uso ya sea Xcode Cloud para integración estrecha con App Store Connect, o lanes de Fastlane en un CI como GitHub Actions cuando quiero más control, y gestiono el firma de código de forma reproducible para que no dependa del portátil de una persona.

La red de seguridad es monitoreo de crashes más una bandera de apagado de funcionalidad, para que un lanzamiento defectuoso pueda desactivarse sin esperar a que un nuevo build pase la revisión.

Los secretos como tokens y contraseñas van en el Keychain, que está cifrado y respaldado por hardware — nunca en UserDefaults, que es solo un plist sin cifrar. Los flujos sensibles se protegen con biometría a través del framework LocalAuthentication, siempre con un respaldo de código de acceso.

Del lado de la red mantengo App Transport Security activado, para que las conexiones sean HTTPS con TLS moderno por defecto. Y en privacidad, declaro un privacy manifest con los datos que la app y sus SDK recopilan y las APIs de razón requerida que usa, y solicito permiso de rastreo antes de tocar el identificador de publicidad. La mentalidad es minimización de datos — los datos más seguros son los que nunca recopila, lo cual también es un argumento para hacer el procesamiento en el dispositivo.

La inferencia en el dispositivo gana en cuatro cosas: privacidad, porque los datos nunca salen del dispositivo; latencia, porque no hay ida y vuelta de red; soporte sin conexión; y costo, porque no hay factura por llamada. Apple lo acelera con el Neural Engine.

La caja de herramientas es Core ML para ejecutar modelos entrenados, Create ML para entrenarlos, y frameworks de tareas como Vision para imágenes, Natural Language para texto y Speech para transcripción — y Apple Intelligence está llevando las funciones generativas en el dispositivo más lejos. Mi regla es ejecutar en el dispositivo siempre que la tarea quepa, y volver a un modelo de servidor solo cuando el trabajo genuinamente exceda lo que el dispositivo puede hacer. Un ejemplo concreto es la búsqueda semántica: incrustar contenido con un modelo pequeño, almacenar los vectores localmente y clasificar por similitud — completamente privado y sin conexión.