Últimos articulos

🔄 Sincronizar una base de datos local con un servidor parece sencillo hasta que la aplicación tiene que funcionar sin conexión. Mientras no hay red, el usuario puede crear, editar y borrar datos. Cuando la conexión vuelve, necesitamos saber exactamente qué ha cambiado para enviar solo esas operaciones. Consultar toda la base de datos cada vez puede servir en una prueba sencilla, pero termina desperdiciando tiempo, batería y datos móviles.

🚀 La pantalla de lanzamiento es lo primero que vemos al abrir una aplicación en iOS. Aparece de inmediato, antes incluso de que la interfaz esté preparada, y desaparece en cuanto SwiftUI puede mostrar la primera vista. Es un instante muy breve, pero influye bastante en la sensación de fluidez que transmite la aplicación.

Aquí está el detalle que suele provocar confusión: aunque el proyecto esté creado por completo con SwiftUI, la pantalla de lanzamiento no es una vista SwiftUI. La dibuja el propio sistema a partir de una configuración estática incluida en la aplicación. En ese momento nuestro código todavía no controla la interfaz.

Las esquinas redondeadas de una interfaz suelen parecer un detalle menor hasta que aparecen varias capas anidadas. Una tarjeta con radio de 28 puntos y un panel interior con radio de 20 pueden quedar razonablemente bien, pero esos valores no garantizan que ambas curvas mantengan la misma separación. Cuando cambia el padding, el tamaño del componente o la geometría del dispositivo, el desajuste se vuelve visible.

SwiftUI tiene dos formas que evitan calcular esos radios a mano: ContainerRelativeShape y, desde los SDK de la generación 26, ConcentricRectangle. Las dos se basan en la forma que contiene la vista que lo aplica, pero no expresan exactamente la misma intención. La primera obtiene una versión con márgen de la forma completa; la segunda trabaja con un rectángulo cuyas esquinas pueden resolverse individualmente respecto a las esquinas del contenedor.

Al adoptar la concurrencia de Swift es habitual encontrarse con diagnósticos como «sending value of non-Sendable type risks causing data races». El mensaje puede aparecer al llamar a un actor, crear una tarea o entregar un closure a una API, incluso cuando el código no menciona hilos ni parece ejecutar dos operaciones a la vez.

La clave está en dejar de pensar en hilos y observar quién puede acceder a cada valor. Swift divide el programa en dominios de aislamiento: un actor, el actor principal y determinadas tareas pueden ejecutar código de forma independiente. Cuando un valor cruza de uno de esos dominios a otro, el compilador necesita saber que ambos no podrán modificar simultáneamente el mismo estado. Sendable expresa precisamente esa garantía.

Xcode Cloud permite implementar Integración Continua sin mantener servidores: conecta el repositorio, ejecuta pruebas, archiva la aplicación y distribuye una compilación. Sin embargo, un flujo de entrega contínua real suele necesitar tareas que no forman parte de un simple xcodebuild: instalar una herramienta, validar archivos generados, preparar notas de una versión o avisar a un servicio externo.

Los scripts personalizados cubren ese espacio. No sustituyen las acciones del flujo de trabajo, sino que añaden lógica en tres momentos concretos de la ejecución. Entender esos límites resulta esencial: el mismo script que ahorra trabajo también puede filtrar un secret (o clave), ralentizar cada compilación o publicar dos veces una versión si no se diseña como una pieza de infraestructura reproducible.