Una corrección de accesibilidad de dos líneas que necesitó un teléfono real para comprobarse
Corrección chica, camino molesto para verificarla: la auditoría de accesibilidad en Deep Cut Atlas encontró un punto donde VoiceOver no podía distinguir cuál playlist estaba vinculada en ese momento. La fila que mostraba un checkmark junto a la playlist vinculada no tenía ningún trait de accesibilidad, VoiceOver leía cada fila igual, solo el nombre de la playlist, sin forma de saber cuál estaba seleccionada. La corrección fue de dos líneas: rastrear si la fila está vinculada, y después aplicar condicionalmente .accessibilityAddTraits(.isSelected). Ya había implementado el mismo patrón exacto en otra parte de la app para un chip de filtro, así que esto fue solo copiar algo que ya funcionaba bien.
Acá está la parte que tomó más tiempo que la corrección: esta pantalla solo se llena con una llamada en vivo a la API de Apple Music, y esa API no funciona para nada en el Simulador de iOS. No es “inestable,” simplemente no devuelve nada. Así que la única forma de ver si el cambio de dos líneas rompía algo era un iPhone real, físico.
Traté de manejar todo el proceso a través del CLI de gestión de dispositivos de Apple (devicectl): build, instalar, lanzar, sin intervención manual. Se quedó a exactamente un paso de la meta: el lanzamiento falló porque el teléfono estaba bloqueado. No es un bug, es solo física, Apple no deja abrir la interfaz de una app en una pantalla que nadie está mirando. Ese paso necesitaba un desbloqueo real en el dispositivo real.
Una vez desbloqueado, me choqué con una segunda pared: la herramienta de espejado de pantalla para manejar taps remotamente reportaba “no window” aunque el teléfono y la app estaban bien. Resultó ser un hueco conocido que de hecho había diagnosticado en una sesión anterior, la herramienta solo se auto-recupera de una conexión “paused,” no de una “no window,” porque no guarda en caché el handle de la ventana para reconectarse a él. La corrección ahí no fue un script, fue reiniciar toda la conexión de la herramienta.
Lección: “verificar en el dispositivo” suena como un solo paso. En la práctica es una cadena, desbloquear, hacer build, instalar, lanzar, reconectar la automatización, y recién entonces revisar lo que importa, y que falle cualquier eslabón detiene toda la cadena, incluso para un cambio tan chico. Código chico, infraestructura real.
Lecturas relacionadas
Lo que encontró una auditoría de accesibilidad en mis propias insignias de SwiftUI
Texto del mismo tono sobre su propio fondo con 18% de opacidad mide 1.27:1 sin importar qué color elijas, y la única insignia que pasó lo hizo poniéndose en negrita en vez de cambiar de color.
Verificar una solución en un ajuste extremo reveló un segundo bug
Los títulos largos se truncaban exactamente como estaba diseñado. La insignia de una sola palabra, el campo 'demasiado corto para necesitar un límite de línea alguna vez', se dividió con guion en 'Al-bum' apilado dentro de una cápsula.
Solo arreglé la captura que me pidieron, no las otras que también estaban rotas
Una captura de marketing recapturada parecía terminada, hasta la pregunta desinflante: ¿de verdad esta es toda captura que se había pedido? Las otras tres del mismo conjunto también estaban desactualizadas, cada una a su manera.