Capturas de pantalla para una app sin simulador

Deep Cut Atlas tiene una tarjeta provisional en la portada de este sitio desde el primer día, con un enlace de “Sigue el progreso en el dev log” y nada más. Construirle una página de marketing real dependía de una sola cosa: capturas de pantalla. Y conseguirlas para esta app en particular resultó más interesante de lo esperado, porque el camino obvio no funciona.

El camino obvio no funciona. MusicKit, el framework sobre el que está construido Deep Cut Atlas, no tiene soporte alguno en el simulador. No es que sea lento o inestable, simplemente no devuelve nada en el simulador. Capturas reales significaban un iPhone físico, con sesión iniciada en una cuenta real de Apple Music, mostrando mi biblioteca real en una imagen pública de marketing. No me entusiasmaba ese plan, sobre todo porque lo que sea que hubiera en mi biblioteca en el momento exacto de tomar la captura se volvería contenido público permanente.

La app ya tenía la solución, por otro motivo. Como MusicKit no puede correr en el simulador de ninguna forma, la app ya incluye una implementación simulada de su servicio de biblioteca musical, MockMusicLibraryService, usada para las vistas previas de SwiftUI y para la suite de pruebas unitarias. Está ahí desde el desarrollo temprano, construida para resolver un problema completamente distinto (cómo previsualizar la interfaz o correr pruebas contra una API sin soporte en el simulador). Resultó ser justo lo que hacía falta para una sesión de capturas también: correr la app en el simulador como siempre, salvo que la “biblioteca” es un pequeño conjunto de datos fijo en vez de una cuenta real.

Lo único que requería cuidado: ese conjunto de datos no es un espacio de pruebas cualquiera. La suite de pruebas verifica contra él por nombre, cadenas específicas de artistas y álbumes activan ramas de prueba específicas. Editarlo directamente para poner datos “más bonitos” habría roto en silencio pruebas que pasaban por buenas razones. Así que los datos de reemplazo vivieron en una rama descartable y sin confirmar, el código real del producto nunca los vio.

La tarjeta decía “álbum,” la tarjeta no mostraba nada. El primer intento con los datos de reemplazo mostró cada portada de álbum como un cuadro gris con un ícono de nota musical. La app lee las portadas desde un campo de URL, y los datos de muestra del simulador siempre habían dejado ese campo vacío, nadie había necesitado arte real para pruebas o vistas previas. Para una captura de marketing, una pared de íconos de reemplazo anula el propósito por completo. La solución fue casi vergonzosamente simple: la API de búsqueda de iTunes de Apple es gratuita, no requiere autenticación, y devuelve URLs reales de portadas para cualquier cosa en el catálogo. Un pequeño cambio en el segmento de resolución de la URL (de 100x100 a 600x600) y el simulador empezó a mostrar portadas de álbum reales, tomadas de un CDN público, sin necesitar sesión de Apple Music.

Lo que se publicó. Cuatro pantallas, el feed de lanzamientos nuevos, una confirmación de agregar a lista de reproducción, la cola, y el historial de reproducciones recientes, cada una con una breve descripción en una nueva página /apps/deep-cut-atlas. Se reutilizó cada token de diseño que ya existía en el sitio, nada nuevo que mantener. Todavía no hay insignia de App Store porque no hay listado, el botón de acción apunta a este dev log en su lugar, lo cual se sintió más honesto que un botón provisional que no lleva a ningún lado.

Lo que encontré en el camino. Revisar la nueva página en un ancho móvil angosto sacó a la luz un error real, texto recortado en el borde derecho del viewport, y confirmó que no era exclusivo de la página nueva. La portada también lo tiene. Ese quedó registrado como su propio pendiente en vez de meterlo en este cambio, una página de marketing para una app no es el lugar para arreglar un error de diseño de todo el sitio, aunque uno se lo tope por accidente mientras revisa su propio trabajo.