Qué puedes cambiar sin publicar una nueva versión: Apple vs Google
Antes de tocar la ficha de una tienda, hay una pregunta que vale la pena responder: ¿esta edición me va a costar un envío completo, o puede salir sin ruido? Si te equivocas, terminas esperando en una cola de revisión que no habías previsto, o das por hecho que un cambio ya está publicado cuando todavía está pendiente de aprobación. Las dos tiendas responden esa pregunta de formas opuestas, y esa diferencia es la razón por la que mantener las fichas sincronizadas entre ambas resulta tan molesto.
Aquí va la versión honesta, campo por campo: primero la matriz, luego el razonamiento detrás de las reglas de cada tienda para que puedas predecir los casos que esta tabla no detalla.
La matriz
Cada campo habitual de la ficha, y lo que exige cada tienda al cambiarlo. "Nueva versión / publicación" significa que la tienda trata la edición como parte de un envío que tienes que enviar; "revisado" significa que se ejecuta una comprobación humana o automática antes de que se publique.
| Icono de la app | El icono principal va incluido en el binario: cambiarlo requiere un nuevo build. Se revisa junto con ese build. | El icono de la tienda es un recurso de la ficha. Sin nueva versión. Se revisa. |
Dos cosas destacan. Apple canaliza casi todo a través de un registro de versión. Google permite que toda la ficha se mueva por su cuenta. Ninguna tienda se salta la revisión en los recursos que importan: la palabra "revisado" aparece en casi todas las celdas. Así que la pregunta real casi nunca es "¿esto se revisará?", sino "¿esta edición arrastra un envío consigo?".
Apple: un nuevo registro de versión no es lo mismo que un nuevo build
Esta es la distinción que confunde a la gente. En la App Store, editar tus capturas, nombre, subtítulo, campo de palabras clave o descripción crea una nueva versión de tu ficha. Suena como si eso te obligara a volver a Xcode. No es así. Apple traslada automáticamente tus metadatos actuales a la nueva versión, y un cambio solo de metadatos no necesita código nuevo: adjuntas un build (App Store Connect igual lo exige en la versión) y no cambias nada sobre lo que hace la app. Editas los campos en cola, envías, y un solo ciclo de revisión los cubre todos.
Así que "sin código nuevo, pero igual revisado" es la forma correcta de recordarlo. Sin paso de compilación ni funciones nuevas, pero la edición igual entra en App Review y espera su turno antes de ser pública. Agrupa tus cambios: como un solo registro de versión puede contener capturas nuevas, una descripción reescrita, un subtítulo fresco y palabras clave actualizadas, todo a la vez, no hay razón para gastar un ciclo de revisión separado en cada uno.
El icono de la app es la excepción que sí necesita un build. Tu icono principal está incrustado en el binario y se extrae de él, así que un icono realmente nuevo implica un nuevo build. Lo mismo pasa con los iconos alternativos: tienen que estar incluidos en la app para poder usarse, así que añadir uno es un build, no una edición de la ficha.
Las dos vías de escape de Apple
Texto promocional. Este es el único campo que puedes cambiar sin versión ni revisión. Tiene 170 caracteres, se sitúa encima de la descripción, y se actualiza cuando quieras: útil para una oferta, una nota de lanzamiento o un texto sensible al tiempo. No afecta al posicionamiento en las búsquedas y no forma parte de ningún envío, precisamente por eso es lo más rápido de cambiar en la tienda. Si necesitas algo publicado hoy mismo, este es el campo que puede hacerlo.
Product Page Optimization. PPO te permite probar hasta tres variantes de tus capturas, vistas previas y icono frente a tu página de producto en vivo, sin publicar una nueva versión de la app. Es lo más cerca que Apple llega a cambiar elementos visuales fuera de un envío normal. Dos matices lo mantienen honesto: los metadatos de cada variante igual tienen que aprobarse antes de que arranque la prueba (así que se revisa, no es instantáneo), y cualquier icono que quieras probar ya debe formar parte del binario actual de la app. PPO cambia lo que ven los visitantes; no se salta la revisión.
Google Play: publica la ficha sin una versión
Play funciona al revés. Tu ficha de la tienda (título, descripción breve, descripción completa, capturas, gráfico destacado, icono, vídeo promocional) es editable y publicable por sí sola, sin ninguna versión nueva de la app asociada. Haces las ediciones y aparecen en el resumen de Publicación bajo cambios listos para enviar a revisión. Los envías, pasan por la revisión de Google, y se publican de forma independiente de cualquier build.
Hay algunos detalles que conviene precisar para no exagerar. Los cambios igual se revisan: la revisión de Play también corre sobre las ediciones de la ficha, y elementos como el nombre de la app y el icono se comprueban, así que no es un intercambio instantáneo y silencioso. Y la ficha no puede flotar libre de una app publicada: Play necesita que la app tenga un lanzamiento previo antes de que exista una ficha pública que editar. No puedes publicar una página de tienda independiente para algo que nunca se ha lanzado. La publicación gestionada añade un matiz más que conviene conocer: si está activada, los cambios aprobados esperan hasta que los publiques activamente, lo cual es una función, no un retraso, una vez que lo esperas.
La asimetría, y por qué te cuesta tiempo
Alinea los dos modelos y la separación es clara. Apple ata casi cualquier edición de texto e imagen a un registro de versión y un ciclo de revisión, con el texto promocional y PPO como las únicas formas de evitarlo. Google desacopla la ficha del lanzamiento por completo, revisa las ediciones, y las publica en su propio calendario mientras la app ya exista.
Esa asimetría sale cara sin que lo notes cuando gestionas ambas tiendas. La misma renovación de capturas es un envío con registro de versión en una tienda y una actualización de ficha independiente en la otra. Reescribir una descripción es una versión revisada en Apple y un cambio de ficha revisado en Google. El contenido es el mismo; la mecánica no lo es, así que un cambio que en Play es una sola acción se convierte en una acción distinta en la App Store, y es fácil publicar uno y olvidarse del otro, o dar por hecho que algo ya está en vivo en Apple cuando todavía está en revisión.
Dónde encaja Mokbi
Esta asimetría entre tiendas es la razón por la que una herramienta de publicación se gana su lugar. Mokbi empezó como un editor de capturas, pero una ficha es texto e imágenes juntos, así que diseña el set de capturas y redacta el texto de la ficha para ambas tiendas en un solo sitio: nombre, subtítulo, campo de palabras clave y descripción para App Store; título, descripción breve y descripción completa para Play. Obtienes los campos que cada tienda realmente indexa, adaptados a esa tienda, en lugar de un solo bloque de texto que pegas dos veces.
Después traduce toda la ficha (capturas y texto) a 50 idiomas, así que un cambio que haces una sola vez llega al campo correcto en cada mercado en lugar de quedarse en inglés en una ficha que en todo lo demás está localizada. Y publica: Mokbi envía la ficha terminada directo a Google Play a través de la Play Developer API, y la deja preparada en App Store Connect lista para enviar (Apple sigue exigiendo el Enviar final y el ciclo de revisión de su lado, que es una regla de Apple y precisamente la asimetría entre tiendas de la que trata este artículo). Esa última revisión también es donde empiezan a correr los relojes de este artículo.