Swift Pills

Dosis rápidas de conocimiento sobre Swift y desarrollo en ecosistemas Apple

Conformar protocolos en Swift 6: navegando por los desafíos de aislamiento de actores

🧩 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.

Posted in

Deja un comentario