Saltar al contenido
Development

Una corrección de accesibilidad de dos líneas que necesitó un teléfono real para comprobarse

Por Victor Da Luz
swiftiosaccessibilitydev-logdeep-cut-atlas

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