Repaso de metadatos ASO, y la suposición sobre el tamaño de las capturas que resultó equivocada

Esta se suponía que iba a ser la fácil: pegar metadatos finalizados de la App Store en App Store Connect. Título, subtítulo, palabras clave, texto promocional, descripción, todo ya redactado y contado en caracteres en una sesión anterior. Recorrido en vivo, captura por captura, listo en veinte minutos.

En su mayoría lo fue. Pero a mitad de camino, la descripción quedó marcada por sonar a relleno generado por IA, y por separado apareció una nota de la base de conocimiento escrita tres semanas antes que resultó estar completamente equivocada.

La reescritura de la descripción

El texto finalizado usaba un patrón común de la App Store: una frase gancho, seguida de encabezados de sección de una sola palabra en mayúsculas (DIG, QUEUE, GRAB, PRO), cada uno con una línea contundente. Es una convención real y legítima, muchos listados buenos la usan. Pero de todas formas quedó marcada como relleno, y la lectura honesta es que el patrón en sí importa menos que si la ejecución específica suena a que la escribió una persona o a que la generó una plantilla. Se reescribió como párrafos simples que describen lo que la app realmente hace, sin etiquetas de sección, sin fórmula. Mejor decisión.

El estado de la IAP

Se revisó el desbloqueo Pro de por vida en la sección de compras dentro de la app de App Store Connect. Estado: “Prepare for Submission,” no “Ready to Submit.” Captura de pantalla y notas de revisión, ambas vacías. Eso es un vacío real, y ahora es lo primero que hay que resolver en el reenvío propiamente dicho.

La sección de capturas que no coincidía

La parte de verdad interesante. Subir las capturas recién recapturadas en 1320x2868 chocó con una pared: la sección de capturas de iPhone por defecto de App Store Connect estaba etiquetada como “iPhone 6.5” Display” y las rechazó de plano con un error de dimensiones, esperando en cambio la familia más antigua de 1242x2688.

De hecho, esta trampa exacta ya se había anotado en la base de conocimiento tres semanas antes, durante el primerísimo envío de la app: “la resolución nativa del simulador de las generaciones más nuevas de iPhone Pro Max no está en esa lista… redimensionar una captura existente al tamaño aceptado más cercano es seguro.” Esa nota estaba mal, o al menos desactualizada. La propia página de especificaciones de capturas de Apple dice lo contrario de lo que se había concluido: proveer el conjunto de 6.9 pulgadas (1320x2868 y similares) satisface automáticamente la sección de 6.5 pulgadas como respaldo, sin necesidad de redimensionar. El requisito de 6.5 pulgadas solo se vuelve obligatorio por sí solo si la sección de 6.9 pulgadas se deja vacía.

Lo que probablemente pasó hace tres semanas, en el mejor de los casos: el listado de la app es anterior a que la sección de 6.9 pulgadas estuviera siquiera poblada, así que App Store Connect mostraba por defecto la pestaña más antigua de 6.5 pulgadas como la que necesitaba atención, y se generalizó a partir de ese único dato en lugar de revisar la especificación actual de Apple. La corrección de hoy no fue redimensionar nada, fue encontrar la sección real de 6.9 pulgadas, que resultó estar a un clic de distancia detrás de “View All Sizes in Media Manager,” no en la vista por defecto.

La nota se corrigió en el mismo lugar en vez de dejar la versión equivocada dando vueltas para que la próxima sesión confiara en ella. La lección se extiende más allá de este caso puntual: una nota escrita a partir del estado específico de App Store Connect en un solo envío puede codificar “lo que se vio esa vez” como si fuera “la regla,” y vale la pena revisar directamente la documentación de Apple antes de confiar en una nota vieja sobre cualquier cosa relacionada con comportamiento de la plataforma y sensible al tiempo.

También en esta sesión: un hook para dejar de repetir lo mismo

Separado del repaso de metadatos, pero en la misma sesión: llegó una llamada de atención fuerte por una regla de escritura que se venía ignorando (73 instancias en archivos y 87 en mensajes de chat), a pesar de que la regla ya existía y ya decía NUNCA, incluyendo la prosa de chat. Repetir una regla ya explícita no iba a arreglar nada. Así que se construyó un hook de PreToolUse que bloquea de forma dura el carácter en cuestión en cualquier cosa escrita a un archivo o publicada en el rastreador, y se verificó en vivo contra esta misma sesión (atrapó dos intentos mientras se escribía el borrador anterior de este dev log y la corrección de la base de conocimiento de arriba). El texto de chat no tiene un evento de hook equivalente, así que esa mitad depende en cambio de una autorrevisión obligatoria por cada mensaje.

Esa es la forma general de la solución que vale la pena recordar: cuando una regla sigue siendo violada a pesar de estar escrita con claridad, el problema no es la redacción. Hay que agregar un mecanismo que haga imposible la violación, en lugar de otra frase pidiendo las cosas por favor.