Últimos articulos

🚀 SwiftTesting llegó en WWDC24 con una de las funcionalidades más esperadas: los tests parametrizados. En lugar de escribir múltiples tests casi idénticos, podemos ejecutar un solo test con diferentes argumentos automáticamente.

⚠️ Sin embargo, la conveniencia de parametrizar puede llevarnos a cometer errores sutiles que comprometen la calidad de nuestras pruebas. Migrar decenas de miles de tests ha revelado patrones problemáticos que debemos evitar.

🔍 Trampa 1: Huecos en la cobertura. Cuando usamos variables opacas en las aserciones, el test puede pasar incluso con bugs reales. Si verificamos que una función devuelve el mismo valor calculado que genera, estamos duplicando la lógica en lugar de validarla.

🔄 Cuando escribes for item in lista, el compilador pone en marcha toda una jerarquía de protocolos que trabajan en segundo plano. Lo que parece una simple iteración es en realidad un sistema elegante basado en Sequence e IteratorProtocol.

🎯 En Swift, Sequence es el protocolo base que permite iterar sobre una colección de elementos. Su único requisito es proporcionar un iterador mediante el método makeIterator(). El iterador, a su vez, solo necesita implementar un método: next(), que devuelve el siguiente elemento o nil cuando termina.

🔒 Garantizar seguridad entre hilos es uno de los retos más complejos en desarrollo iOS. Un simple diccionario compartido puede provocar condiciones de carrera, crashes o estados corruptos si varios hilos escriben y leen simultáneamente sin la sincronización adecuada.⚙️ La solución clásica con GCD usa colas concurrentes con lecturas síncronas y escrituras asíncronas. Pero sin el flag .barrier, las lecturas y escrituras pueden solaparse, creando inconsistencias. El patrón recomendado es lecturas concurrentes y escrituras serializadas mediante barriers.🚀 OSAllocatedUnfairLock llega en iOS 16 como el wrapper moderno de os_unfair_lock. Gestiona memoria automáticamente, es Sendable, y su API withLock elimina el riesgo de olvidar liberar el lock. Usa la misma primitiva del kernel que su predecesor pero sin interoperabilidad con C.🛡️ Los actores de Swift Concurrency eliminan colas y barreras por completo. Aislan el estado mutable garantizando que solo una tarea pueda acceder a él simultáneamente. El compilador y el runtime manejan la sincronización sin bloqueos explícitos ni riesgo de deadlocks.🔬 Internamente, los actors gestionan una cola de tareas pendientes y un flag para indicar si están activos. Cuando una tarea llama a un método del actor, Swift la encola. El actor procesa su cola secuencialmente, ejecutando una tarea a la vez, lo que garantiza aislamiento total del estado.⚡ Si priorizas rendimiento y seguridad con GCD, usa .barrier. Para compatibilidad total con Swift 6 y simplificar tu código, los actores son el camino. Apple recomienda migrar de os_unfair_lock a OSAllocatedUnfairLock para garantizar comportamiento correcto del locking.👨‍💻 ¿Ya estás usando actores en tus proyectos o sigues confiando en GCD? La evolución del ecosistema Swift apunta claramente hacia concurrencia estructurada y la seguridad de datos por defecto.

🧩 Uno de los aspectos más complejos de la concurrencia en Swift es hacer que tipos aislados a actores conformen protocolos que no fueron diseñados con concurrencia.🎯 El problema es común: tienes un tipo marcado con @MainActor que necesita conformar Equatable, Codable o cualquier otro protocolo estándar.⚠️ Aparece el temido error: Conformance crosses into main actor-isolated code and can cause data races.🔍 La raíz del problema está en que protocolos como Equatable esperan implementaciones nonisolated, es decir, que funcionen desde cualquier contexto.🛠️ Swift 6.2 introduce isolated conformances (SE-0470), que permiten restringir una conformación a un actor global específico.💡 Con esta nueva característica, puedes escribir tipo como extension ImageModel: @MainActor Equatable y el compilador entiende la restricción de contexto.🚀 El ajuste InferIsolatedConformances, que hace esto automáticamente cuando está habilitado, parte del nuevo enfoque Approachable Concurrency en Xcode 26.🔄 Antes de Swift 6.2, la solución era @preconcurrency conformances (SE-0423), que funciona, pero semánticamente sugiere que el protocolo está desactualizado y no es seguro.⚡ Otra alternativa es usar nonisolated + MainActor.assumeIsolated, aunque es verboso y puede introducir verificaciones en tiempo de ejecución peligrosas.🎨 Existe un enfoque alternativo poco conocido: diseñar tipos como no Sendable y nonisolated desde el inicio, dejando que el compilador prevenga su escape.🔒 Los tipos no Sendable quedan automáticamente atrapados en el dominio de aislamiento donde se crean, sin necesidad de marcas explícitas de actor.🧠 Este principio no Sendable por definición puede ser la solución más simple o la más compleja, dependiendo de las necesidades internas del tipo.👨‍💻 Dominar estos patrones de conformance es esencial para migrar proyectos a Swift 6 sin comprometer la seguridad de datos.​​​​​​​​​​​​​​​​ Lamentablemente no hay una regla o patrón eficaz y la mejor implementación depende del caso concreto.

🎯 Aunque parecen similares, estos tres componentes nativos de SwiftUI tienen propósitos completamente distintos.

Elegir el correcto marca la diferencia entre una interfaz intuitiva y una confusa.

📊 Gauge es para mostrar valores medidos dentro de un rango. Introducido en iOS 16, es ideal para representar temperatura, nivel de batería o uso de CPU.

A diferencia de los otros, es de solo lectura: el usuario no puede interactuar con él para cambiar el valor.