Ejemplos de notas de versión para el App Store: textos de Novedades que dicen qué cambió (2026)

Unas buenas notas de versión del App Store responden a una sola pregunta: ¿qué cambia para mí después de actualizar? Todos los ejemplos de notas de versión de este artículo siguen el mismo patrón. Empieza por el cambio que el usuario va a notar, nombra cada corrección de forma concreta y deja fuera todo lo que no pueda ver. La propia guía de Apple para el campo What's New in This Version (Novedades de esta versión) dice lo mismo: pide funciones nuevas, mejoras de interfaz o correcciones de errores y recomienda contar a los usuarios «los detalles concretos de los cambios, mejoras o correcciones de la versión».

¿Qué reglas tienen las notas de versión en App Store Connect y Google Play?

El campo Novedades de Apple admite 4000 caracteres y es obligatorio en todas las versiones posteriores a la primera. Google Play admite 500 caracteres Unicode por idioma y prohíbe el contenido promocional.

A octubre de 2026, la ayuda de Play Console indica: «No uses las notas de la versión con fines promocionales ni para pedir a los usuarios que realicen acciones». En Apple, pon el texto de marketing en el Texto promocional. Ese campo admite 170 caracteres, aparece encima de la descripción y Apple permite actualizarlo sin enviar una versión nueva.

¿Cómo son unas buenas notas de versión del App Store?

Unas buenas notas de versión nombran la situación en la que estaba el usuario y el resultado que obtiene ahora. Los ejemplos siguientes son de una app ficticia de seguimiento de hábitos. Las versiones vagas son el tipo de notas que se escriben a última hora.

Si una corrección es demasiado técnica para explicarla en una frase, probablemente el usuario no la notará, así que puede ir bajo una única línea de «mejoras de estabilidad» al final. La directriz 2.3.12 lo permite para correcciones menores, pero no para cambios reales de funciones.

¿Hay una plantilla de notas de versión que pueda reutilizar?

Sí. Una plantilla reutilizable tiene un titular y luego las secciones Nuevo, Mejorado y Corregido. Guárdala en tu repositorio junto al changelog y rellénala cuando crees la rama de release, no después de subir la compilación.

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

Para Google Play, reduce esas mismas notas al titular más las dos o tres viñetas principales para que quepan en 500 caracteres. Pon las etiquetas de cada idioma en líneas propias, por ejemplo <en-US> y </en-US>. Quita la línea final en Play, porque pide al usuario que haga algo.

¿Cómo se convierten los pull requests fusionados en notas de versión?

Para convertir los pull requests fusionados en notas de versión, filtra los cambios que el usuario no puede ver y reescribe cada cambio restante como un síntoma o un resultado. Sigue estos pasos en cada versión.

1. Exporta los títulos de los pull requests fusionados desde la última etiqueta y elimina todo lo que el usuario no ve, como refactorizaciones, actualizaciones de dependencias y cambios de CI.
2. Reescribe cada elemento restante como un síntoma o un resultado. «Fix nil coordinator» pasa a ser «Corregida una pantalla en blanco después de iniciar sesión con Apple».
3. Ordena los elementos según a cuántos usuarios afectan, no según cuánto trabajo de ingeniería costaron.
4. En App Store Connect, crea la versión nueva y borra el texto de Novedades copiado antes de pegar las notas nuevas, porque los metadatos de la versión anterior se arrastran.
5. Pega las notas en todas las localizaciones que admitas, traducidas o al menos revisadas en cada idioma, para que los usuarios de otras regiones no vean las notas de la versión anterior.
6. Para Play, pega la versión abreviada dentro de las etiquetas de idioma y confirma que cada idioma se queda por debajo de 500 caracteres.
7. Lee las notas en voz alta una vez. Si una frase necesita que un desarrollador la explique, reescríbela.

¿Qué deben decir las notas de versión de un hotfix?

Las notas de un hotfix deben nombrar la versión con el fallo, describir el síntoma que ya está corregido y explicar a los usuarios afectados qué ocurre después de actualizar. Apple no permite volver a una versión anterior en el App Store, así que una corrección siempre se publica como una versión nueva.

Un ejemplo: «Corregido un problema de la 3.4.0 por el que los recordatorios dejaban de saltar para algunos usuarios. Los recordatorios que configuraste antes de actualizar se reanudarán automáticamente». Los usuarios afectados saben que deben actualizar y los que no lo estaban ven que la corrección no les concierne. No culpes al sistema operativo ni prometas fechas para futuras correcciones. Si publicas actualizaciones con un lanzamiento por fases, pausar el despliegue limita cuántos usuarios reciben la compilación con el fallo mientras la corrección está en revisión. Si el hotfix cambia el comportamiento de una función, repasa de nuevo la lista de comprobación para enviar al App Store para que las notas, las capturas y las notas para la revisión coincidan.

¿Puede App Review rechazar una actualización por sus notas de versión?

Sí. Las notas de versión son metadatos y las App Review Guidelines las cubren directamente. La directriz 2.3.12 dice: «Las apps deben describir claramente las funciones nuevas y los cambios de producto en su texto de "Novedades"».

Se permite una redacción genérica para «correcciones simples de errores, actualizaciones de seguridad y mejoras de rendimiento», pero «los cambios más significativos deben enumerarse en las notas». La directriz 2.3.10 prohíbe nombres o imágenes de otras plataformas móviles en los metadatos, lo que incluye Novedades. No describas funciones ocultas tras flags ni nada que no esté en la compilación enviada. La directriz 2.3.1(a) exige además que las funciones nuevas se «describan con detalle en la sección Notas para la revisión», así que pon ahí los pasos para el revisor y una cuenta de demostración, no en las notas públicas. Si recibes una pregunta sobre metadatos, nuestra guía sobre cómo solucionar rechazos del App Store explica cómo responder.

¿Qué problemas con las notas de versión han tenido otros desarrolladores?

Los casos publicados muestran dos tipos de fallo: subidas rechazadas por superar el límite de longitud de una tienda y rechazos de revisión que incluyen el texto de Novedades en sus instrucciones de limpieza.

• Límite de longitud de Play en CI. Un issue de GitHub en una plantilla de despliegue de Flutter informa de un changelog generado por IA que hizo fallar una subida a la prueba interna de Google Play mediante fastlane con: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." Los mantenedores añadieron un script que recorta las notas antes de subirlas: 480 caracteres para Play y 3800 bytes para TestFlight, que mide su límite en bytes.
• Limpieza por la 2.3.10 que incluye Novedades. Un desarrollador en los Apple Developer Forums publicó un rechazo por la directriz 2.3.10 provocado por barras de estado que no eran de iOS en las capturas. Los siguientes pasos indicados por Apple pedían «eliminar todas las apariciones de esta información de tu app y de sus metadatos, incluida la descripción de la app, el texto promocional, la información de Novedades, las previsualizaciones y las capturas de pantalla». Las respuestas aconsejaban rehacer las capturas y revisar todos los campos de metadatos, incluidas las notas de versión.

La conclusión: el límite de longitud es mecánico y falla de forma evidente al subir, mientras que las reglas de revisión se refieren al contenido y se aplican a todos los campos de metadatos. Automatiza una comprobación de caracteres y lee Novedades con el mismo cuidado que tus capturas.

¿Qué deberías revisar antes de enviar las notas de versión?

Antes de enviar, comprueba que las notas describen solo lo que hay en la compilación, que caben en los límites de cada tienda y que sustituyen el texto de la versión anterior en todos los idiomas.

• El titular nombra el cambio que notará la mayoría de los usuarios.
• Todas las funciones o cambios de producto significativos están enumerados, como exige la directriz 2.3.12.
• Cada corrección describe un síntoma que vio el usuario, no código interno.
• Sin funciones ocultas tras flags, sin promesas de futuro, sin números de tickets internos y sin nombres de otras plataformas.
• El texto de Novedades de la versión anterior está borrado y sustituido en todas las localizaciones.
• Las notas de Play tienen menos de 500 caracteres por idioma, van entre las etiquetas de idioma correctas y no incluyen promociones ni llamadas a la acción.
• Los mensajes de marketing se han pasado al Texto promocional en Apple.
• Si también tienes testers de Android, las mismas notas se han revisado frente a tu plan de pruebas cerradas.

Si quieres que alguien más revise los metadatos de tu actualización antes de enviarla, escribe a yagyeshsrbobde@gmail.com con el borrador de tus notas y la lista de cambios de la compilación, o consulta nuestros servicios.