[unowned self] en Swift: ¿cuándo es necesario y cuándo es peligroso?

El dilema eterno: ¿poner [unowned self] o no?

Si alguna vez has escrito en Swift y te has encontrado con closures, seguramente te has preguntado: "¿Necesito escribir [unowned self] dentro de cada closure donde uso self?".

Esta es una de las preguntas más populares en Stack Overflow (decenas de miles de visitas), y con razón. En 2025, con la llegada de nuevas características de Swift (como un mejor analizador de ciclo de vida y verificaciones más estrictas del compilador), la respuesta se ha vuelto aún más matizada.

En este artículo no solo daremos una respuesta seca de "sí" o "no". Analizaremos cómo funciona realmente la gestión de memoria en Swift, cuándo [unowned self] es una salvación y cuándo es una bomba de tiempo, y cuáles son las mejores prácticas para usar en proyectos modernos.

¡Allá vamos! 🚀

Breve explicación de ARC y retain cycles (para principiantes)

Antes de hablar de [unowned self], recordemos cómo funciona el Automatic Reference Counting (ARC).

ARC es un mecanismo de conteo de referencias. Cada objeto en Swift (instancia de una clase) tiene un contador de referencias. Cuando creas una nueva referencia a un objeto (por ejemplo, lo asignas a una propiedad o lo pones en un array), el contador aumenta. Cuando la referencia desaparece, disminuye. Cuando el contador llega a cero, el objeto se destruye.

El problema surge cuando dos objetos se referencian mutuamente (referencia cíclica). Imagina:

class Parent {\n    var child: Child?\n}\n\nclass Child {\n    var parent: Parent? // Referencia fuerte de vuelta a Parent\n}

Si creas un par Parent y Child y estableces ambas referencias, se mantendrán mutuamente para siempre. ARC nunca pondrá sus contadores a cero. Esto se llama retain cycle (ciclo de referencias fuertes).

Los closures también son tipos por referencia. Cuando un closure captura self (por ejemplo, para llamar a un método), almacena una referencia fuerte al objeto. Si el objeto, a su vez, almacena una referencia fuerte al closure (por ejemplo, como propiedad), se produce el mismo ciclo.

Weak vs Unowned: ¿cuál es la diferencia?

Para romper el ciclo, usamos weak o unowned.

weak self

\n
• Siempre es opcional (self?).
\n
• La referencia no incrementa el contador de ARC.
\n
• Cuando el objeto se destruye, la referencia weak se vuelve automáticamente nil.
\n
• Seguro — siempre verificas con guard let self = self else { return }.
\n

unowned self

\n
• No es opcional (self sin signo de interrogación).
\n
• La referencia no incrementa el contador de ARC.
\n
• Cuando el objeto se destruye, la referencia unowned no se vuelve nil. Se convierte en un puntero colgante (dangling pointer).
\n
• Acceder a esa referencia después de la destrucción del objeto provoca un crash (EXC_BAD_ACCESS).
\n

Punto clave: unowned es una promesa al compilador: "Garantizo que el objeto estará vivo mientras se ejecute este closure". Si te equivocas, la aplicación se caerá.

Cuándo usar [unowned self] (y cuándo no)

Analicemos escenarios reales de la práctica de desarrollo iOS en 2025.

Caso 1: [unowned self] está bien (e incluso es preferible)

Usa [unowned self] cuando estés absolutamente seguro de que self estará vivo en el momento de la ejecución del closure. Un ejemplo típico es un closure que se ejecuta de forma síncrona dentro de un método del objeto, y se garantiza que el objeto no será destruido antes de que el closure termine.

class DataFetcher {\n    var data: Data?\n    \n    func fetchData() {\n        // Este closure se ejecuta de forma síncrona dentro del método\n        let processCl