Las capturas de pantalla de la App Store que nadie actualizó en dos semanas

Deep Cut Atlas está en medio de un reenvío a App Review en este momento (una corrección de rechazo aparte, otra historia). Mientras se revisaba la lista de verificación del reenvío, surgió una pregunta al pasar: ¿las capturas de pantalla de la App Store siguen siendo buenas? Nadie se lo había preguntado en dos semanas.

No lo eran.

Dos carpetas, dos trabajos distintos

El repositorio tiene dos carpetas de capturas que parecen que deberían ser intercambiables y no lo son: design/app-store-screenshots/ y design/marketing-screenshots/. El conjunto de marketing se actualizó hace poco para la página de producto de imperfectsystems.com. Por poco se asumió que eso también cubría el listado de la App Store, ya que muestran las mismas cuatro pantallas de la app. No comparten historial de git en absoluto, y resultó que el conjunto de la App Store tenía exactamente un solo commit, el envío original de hace dos semanas y aproximadamente una docena de cambios de interfaz publicados atrás.

Peor aún, incluso si se hubiera querido reutilizar el conjunto de marketing, la resolución está mal. App Store Connect de Apple exige una coincidencia exacta de píxeles según la clase de dispositivo, 1320x2868 para el tamaño de iPhone insignia actual. Las capturas de marketing se tomaron a través de una ventana reflejada de un dispositivo físico y salieron en 406x890, lejos de eso. Problema distinto, restricción distinta, sin atajo entre ambos.

Conseguir arte real para los datos de prueba

Las capturas se generan a partir de una corrida del Simulador con datos simulados, ya que MusicKit no funciona en el Simulador en absoluto. Los datos de prueba existentes sirven bien para las pruebas unitarias y son pésimos para una captura de pantalla: cada álbum tenía una URL de portada nula, así que todo el feed se renderizaba como una pared de mosaicos grises de relleno. Sin embargo, el Simulador tiene acceso completo a la red, así que se extrajo arte de portada real desde la API pública de búsqueda de iTunes de Apple y se conectaron las URLs a los datos de prueba de forma temporal, se capturó, y luego se revirtió. El mismo patrón de rama descartable que usaron las capturas del lanzamiento original, solo que nunca se confirmó de forma permanente, ya que la app en sí nunca necesita arte real incrustado en sus datos de prueba.

Una búsqueda en iTunes devolvió una portada completamente equivocada, el remix de un artista distinto con un título parecido. Se detectó comparando los encabezados HTTP lado a lado contra una URL que ya funcionaba correctamente, en lugar de asumir que el primer resultado de la búsqueda era el correcto. Valió la pena el minuto extra.

El caché que sobrevivió a la reconstrucción

Después de conectar el arte nuevo, la mayoría de los álbumes obtuvieron portadas reales de inmediato. Unos pocos, tercamente, seguían mostrando espacios en blanco, en la misma reconstrucción exacta. Resultó que la app tiene su propio caché JSON en disco para el feed de Descubrir, y sobrevive intacto a una simple reconstrucción y reinstalación, porque el binario cambia pero el contenedor de datos de la app no. Solo un simctl uninstall completo lo limpia de verdad. Eso costó bastante confusión genuina antes de rastrearlo, así que ahora quedó anotado como su propia nota en vez de algo que habrá que redescubrir la próxima vez.

Ni siquiera “correcto” fue suficiente

Primer intento de la captura de Descubrir: arte real cargando en todos lados donde debía. Parecía terminado. Después llegó la pregunta de seguimiento obvia que debería haberse hecho antes: ¿no se necesitan estas capturas para el envío, para empezar? Justo, y eso llevó a revisar de nuevo la propia afirmación de que la actualización de las capturas de marketing ya cubría esto, cosa que no era cierta.

Segundo intento, después de corregir eso: el orden predeterminado del feed puso dos álbumes intencionalmente ficticios de “próximamente” justo arriba de todo, ambos en blanco por diseño porque todavía no existen. Técnicamente correcto, pero aun así una mala primera impresión para una captura cuyo único trabajo es verse bien. Se cambió a un modo de orden distinto y completamente real que la app ya trae (Artista A-Z) en lugar de manipular los datos, y dos álbumes reales que por casualidad empiezan con las letras correctas quedaron arriba en su lugar.

Tercer intento: todavía quedaba un marcador de posición visible unas filas más abajo, los mismos álbumes de preestreno. Ahí quedó claro que una captura de marketing no le debe a nadie una demostración de cada caso límite que maneja la app. Se sacaron por completo las entradas ficticias de preestreno del feed para esta captura. Cero marcadores de posición, el primer intento que de verdad resultó bueno.

Tres rondas de “parece terminado” que no lo estaban, cada una detectando algo que la ronda anterior había pasado por alto. Ninguna de las correcciones individuales fue difícil. Llegar hasta ahí exigió estar dispuesto a seguir diciendo “todavía no” en lugar de aceptar el primer resultado que se veía plausible.

Una que no se pudo automatizar

La captura del desbloqueo Pro necesitaba el botón de compra real de StoreKit con su precio en vivo, y la configuración de pruebas de StoreKit solo se carga cuando la app se ejecuta desde Xcode mismo, nunca desde una compilación por línea de comandos. Eso es una barrera dura de las herramientas, no una preferencia. Esa pantalla en particular tuvo que ejecutarse una vez desde Xcode a mano, y luego la automatización retomó el control para la navegación y la captura de pantalla real una vez que la compilación correcta estaba activa. Un momento pequeño, pero un ejemplo claro de dónde está el límite honesto de la automatización: es un comportamiento de carga de la configuración de StoreKit, no un problema de permisos o de automatización de interfaz, así que ninguna cantidad de ingenio sustituye al único entorno que realmente la carga.

Al final, las cuatro capturas se publicaron, con la interfaz actual, reales donde correspondía. Quedó registrado como su propio issue en lugar de mezclarlo con la corrección del reenvío, porque en realidad es una lección aparte: verificar las suposiciones sobre trabajo “ya terminado” antes de apostar un reenvío a ellas.