Últimos articulos

🔄 Las tareas en segundo plano son una de esas capacidades de iOS que parecen sencillas hasta que intentas implementar alguna de ellas. La idea es muy tentadora: permitir que una app actualice datos, limpie cachés o prepare contenido aunque el usuario no la tenga en primer plano. En SwiftUI, además, Apple ofrece una integración bastante cómoda mediante el modificador .backgroundTask, pero eso no significa que el sistema vaya a ejecutar nuestro código cuando queramos ni durante todo el tiempo que nos gustaría.

📐 Las sheet de SwiftUI funcionan muy bien cuando aceptas los tamaños que el sistema propone. El problema aparece cuando tu interfaz no encaja en niguno de esos tamaños. Una vista pequeña queda flotando dentro de un sheet demasiado alto. Una vista algo más grande puede quedar cortada. Y una pantalla que solo necesita presentar una confirmación breve termina ocupando gran parte de la pantalla sin necesidad.

Desde iOS 16, SwiftUI permite controlar la altura de una hoja con presentationDetents, usando valores como .medium, .large, .height(...) o .fraction(...). Es una mejora enorme frente al comportamiento inicial de los sheets, pero sigue teniendo una limitación importante: no existe un detent nativo que diga simplemente “mide el contenido y usa esa altura”.

🧩 En SwiftUI es muy tentador convertirlo todo a String antes de pintarlo en pantalla. Un número se interpola, una fecha se pasa por un DateFormatter, una cantidad se concatena con un símbolo de moneda y un porcentaje se multiplica a mano. Funciona, sí, pero también es una forma rápida de llenar la interfaz de pequeños futuros problemas: separadores decimales incorrectos, indicador de divisa mal colocados, fechas que resultan poco naturales o campos de texto que aceptan valores imposibles.

🧠 ARC (Automatic Reference Counting) lleva con nosotros desde el primer día en Swift, pero la mayoría de desarrolladores solo conoce su capa exterior: los objetos se retienen, se liberan y se destruyen cuando el contador llega a cero. Lo que muy pocos saben es que el modelo interno ha cambiado de forma significativa desde las primeras versiones del lenguaje. Esos cambios no son detalles de implementación irrelevantes: explican por qué ciertas decisiones de diseño tienen un coste, y por qué el runtime se comporta de una manera u otra en situaciones límite.

🔄 .refreshable es uno de esos modificadores de SwiftUI que parece trivial hasta que algo falla de forma inexplicable. Lo añades a una lista, le pasas tu función async, y todo funciona en el simulador. Pero en producción, o simplemente bajo condiciones ligeramente distintas, la carga se interrumpe a la mitad, el indicador de refresco desaparece antes de tiempo, o una petición de red lanza un error. El origen del problema casi nunca está donde lo buscas.