Últimos articulos

🔒 Swift está diseñado para favorecer la inmutabilidad por defecto. Los parámetros de una función son constantes, lo que evita efectos secundarios accidentales y simplifica el razonamiento sobre el código. Pero hay situaciones en las que necesitas que una función modifique directamente el valor que recibe, no que devuelva una copia transformada. Para eso existe inout.

🔄 El mecanismo interno de inout no es paso por referencia al estilo de C o C++, aunque lo parezca. Swift implementa un modelo llamado copy-in copy-out: al llamar a la función, el valor se copia en un almacenamiento local; la función opera sobre esa copia; y al retornar, el valor modificado se escribe de vuelta en la variable original. El compilador puede optimizar este proceso usando directamente la dirección de memoria original cuando es seguro hacerlo, pero el contrato semántico sigue siendo el de copia.

💤 Una propiedad lazy en Swift es una propiedad almacenada cuyo valor no se calcula hasta que se accede a ella por primera vez. A diferencia de las propiedades almacenadas habituales, que se inicializan en el momento en que se crea la instancia, las propiedades lazy difieren ese trabajo hasta que realmente se necesita. La sintaxis es directa: basta con anteponer la palabra clave lazy a una declaración de var.

🧩 associatedtype es una de esas características del sistema de tipos de Swift que pasan desapercibidas al principio, pero que están detrás de casi todo lo que usamos a diario. El protocolo Sequence, la colección Array, el propio protocolo View de SwiftUI: todos ellos dependen de esta misma pieza. Entender cómo funciona no es solo un ejercicio teórico; es comprender el contrato que Swift establece entre la abstracción y la seguridad de tipos en tiempo de compilación.

🎭 onAppear es uno de esos modificadores que parece trivial hasta que deja de comportarse como esperas. En configuraciones sencillas funciona exactamente como esperas: la vista aparece, onAppear se dispara; desaparece, onDisappear hace lo propio. El problema llega cuando añades esa lógica en un TabView, en una pila de navegación o en una lista de miles de filas, y de repente el comportamiento cambia de forma que no cuadra con el modelo mental que tenías.

🧩 Hay una regla que circula sin parar en entrevistas técnicas de iOS: los structs van al stack y las clases van al heap. Es fácil de memorizar, suena convincente y, en la mayoría de los casos sencillos, parece funcionar. El problema es que no describe cómo Swift gestiona la memoria en la práctica. En cuanto hablamos de código real, la regla se rompe. Entender el modelo de verdad requiere empezar por otro sitio: la semántica, no el almacenamiento.