LaunchLint Academy
La respuesta breve
- App Store Connect separa propiedades generales y campos de una versión. Su disponibilidad para editar o localizar depende del tipo y estado.
- Compara nombre, subtítulo, keywords, descripción, screenshots, URLs, edad, review information y What's New con el build exacto.
- Localizar no es traducir literalmente: búsqueda, promesa, imágenes, soporte y textos legales deben funcionar en cada mercado.
- Antes de aprobar la ficha, realiza un ensayo editorial con una segunda persona y el build de producción instalado. Esa persona debe leer la página como un usuario nuevo, abrir soporte y privacidad en una sesión anónima, buscar cada beneficio anunciado dentro de la app y verificar que precios, requisitos, regiones y funciones premium estén explicados. Repite el ejercicio para cada idioma activo, porque una traducción completa puede conservar capturas antiguas, keywords irrelevantes o una URL dirigida a otra región. Guarda después un snapshot de todos los campos, el número de build, la fecha y la persona responsable. Si el equipo cambia una función, un SDK, una edad objetivo o el modelo de cuenta, reabre la matriz en lugar de copiar la versión anterior. Este procedimiento convierte los metadatos en un artefacto auditable: permite saber qué vio Apple, qué afirmación estaba respaldada por el producto y qué dato debe corregirse ante una pregunta de review. Los validadores automáticos ayudan con límites, enlaces y campos vacíos, pero la aprobación final necesita comparar el significado de la ficha con la experiencia real.
1. Inventariar todas las capas de metadata
App Store Connect mezcla información compartida por la app y datos propios de una versión de plataforma. Nombre, idioma principal, categoría o bundle no siguen el mismo ciclo que screenshots, descripción, soporte, What's New y indicaciones para el equipo de revisión. Tratarlo como un formulario único oculta bloqueos y produce contradicciones.
Crea una matriz con owner, locale, fuente, fecha, aprobación y build representado. Marca si el campo es público, privado para review o derivado del binario. Así un cambio de marketing no deja antiguas la política de privacidad, las credenciales o una URL crítica.
Matriz:
- Datos generales y de versión
- Campos públicos y privados
- Valores localizables
- Edición según estado
- Owner y aprobación
- Relación con build
2. Nombre, subtítulo y categoría precisos
La referencia actual limita nombre y subtítulo a 30 caracteres cada uno. Deben identificar el producto y su beneficio principal, no acumular keywords, marcas ajenas o funciones ausentes. Mide texto Unicode real y revisa cómo se corta en dispositivos.
Elige la categoría por el trabajo central de la app. Contrasta el nombre de Store con icono, Home Screen, onboarding, soporte y política de privacidad. Variaciones inexplicadas hacen que usuario y reviewer duden si hablan del mismo servicio.
Comprobar:
- Límites actuales
- Beneficio sin superlativos
- Sin marcas ajenas
- Categoría por función
- Nombre instalado coherente
- Significado local
3. Cubrir intención sin keyword spam
Nombre, subtítulo, keywords y desarrollador pueden contribuir al descubrimiento. Prioriza problema, tarea y audiencia. No repitas mecánicamente términos ya fuertes ni uses competidores para atraer impresiones que la app no satisface.
Crea un set por idioma. Una traducción literal suele perder la consulta local. Vincula cada palabra a una función y un mensaje visible. Si no puedes demostrar la relación, probablemente reducirá conversión y puede parecer engañosa.
Revisión keywords:
- Problema y tarea
- Audiencia
- Lenguaje local
- Sin repeticiones
- Sin competidores
- Función demostrable
4. Alinear descripción y Promotional Text
Explica resultado, recorridos principales y requisitos para alguien nuevo. Ordena por valor. Claims absolutos como anónima, siempre offline o sin tracking exigen evidencia de SDK, backend y configuración production.
Promotional Text puede cambiar sin nueva versión, pero no anunciar una función que el build público aún no contiene. Separa mensaje estable y campaña. Revisa suscripciones, hardware, links y disponibilidad regional contra el artefacto enviado.
Aprobación copy:
- Resultado primero
- Limitaciones visibles
- Claims verificados
- Premium marcado
- Sin futuro como presente
- Prueba en build
5. Tratar URLs como parte del producto
Privacy URL debe abrir una política de privacidad pública y activa; soporte debe ofrecer ayuda o contacto real. Prueba sin login, navegador privado, móvil y red externa. Certificados, redirects, cookie walls o geoblocking pueden bloquear la review.
La página identifica app y responsable y refleja prácticas actuales. Actualízala con SDKs, cuentas, compras o borrado. Asigna monitoring y tiempo de reparación. Haber abierto el link una vez no es pruebas durable.
Preflight URL:
- HTTPS correcto
- Sin VPN
- App identificada
- Contacto vigilado
- Privacy actual
- Locale y móvil
6. Edad, derechos y regiones
La edad debe considerar UGC, WebViews, anuncios, medicina, violencia, apuestas o web abierta, no solo demo. Un feed dinámico puede determinar la respuesta aunque onboarding sea inocuo.
Confirma derechos de marcas, música, imágenes y feeds. Algunas regiones requieren más datos. Documenta la razón de cada respuesta y reabre el formulario cuando cambien moderación, audiencia o fuentes.
política de privacidad:
- UGC incluido
- WebViews
- Ads y regulación
- Licencias
- Audiencia coherente
- Requisitos regionales
7. Campos de versión y What's New
What's New debe nombrar cambios visibles y no repetir mejoras. No describas experiments ni funciones parciales como garantizadas. Relaciona versión, build, screenshots y release setting en el handoff.
Review information necesita cuenta estable, contacto y rutas breves. Explica región, rol, hardware, subscription o feature flag con resultado esperado. El reviewer no conoce tu roadmap ni tus estados internos.
Handoff:
- Versión y build
- Cambios visibles
- Release mode
- Contacto
- Credenciales
- Condiciones especiales
8. Preflight por una segunda persona
Una persona externa abre cada locale, URLs, capturas y build y sigue indicaciones para el equipo de revisión en un dispositivo limpio. Encuentra fallos que un contador de caracteres no detecta.
Guarda snapshot de metadata, versión, build, fecha y aprobación. LaunchLint conecta señales del archivos del proyecto y riesgos, pero sin acceso al Store no puede afirmar que verificó el estado final de App Store Connect.
pruebas final:
- Locales abiertos
- Links externos
- Claims comparados
- Orden visual
- Acceso review
- Snapshot archivado
Preguntas frecuentes
¿Límite de nombre y subtítulo?
Apple documenta actualmente 30 caracteres para cada uno. Confirma siempre la referencia vigente antes del envío.
¿Puedo cambiar screenshots después?
Depende del campo y estado; cambiar capturas aprobadas normalmente requiere una nueva versión.
¿Traduzco las mismas keywords?
No. Investiga la consulta real de cada mercado y evita traducción literal sin intención.
¿LaunchLint verifica todo App Store Connect?
Solo con datos aportados o integración. El archivos del proyecto no sustituye la revisión final de la consola.