Cada vez que shippeas un update, tienes 4.000 caracteres para decirle a Apple qué cambió. La mayoría de developers indie usan menos de 40.
“Bug fixes and performance improvements” no son notas de la versión. Es espacio desperdiciado, y bajo las guidelines 2026 de Apple, podría estar trabajando en contra de la posición de tu app en la store.
Qué hacen realmente las notas de la versión
Las notas de la versión en el App Store sirven a tres audiencias separadas a la vez:
- Usuarios existentes decidiendo si actualizar
- Usuarios potenciales leyendo la sección de historial de versiones de tu product page
- Los sistemas de indexación de Apple evaluando si el update representa desarrollo activo y significativo
La mayoría de developers indie escriben solo para la primera audiencia, o se saltan las notas de la versión por completo porque están presionados de tiempo después de shippear un build. Eso es un error.
El algoritmo de búsqueda del App Store de Apple trata el historial de updates de tu app como una señal. No el número de versión, no el tamaño del binary. El contenido de tus notas de la versión. Una app con notas de la versión descriptivas y específicas a lo largo de un historial de updates consistente señala mantenimiento activo. Una app con “Bug fixes.” en cada slot de update señala lo contrario.
Con el update de guidelines de WWDC26, Apple expandió su derecho declarado de remover apps que “are not updated or improved”. Tu campo de notas de la versión es una ventana directa hacia si tu app ha sido actualizada de forma significativa. Si tus últimas cinco entradas dicen todas “minor improvements”, tu historial de updates se lee como dormant, sin importar lo que realmente se haya shippeado en el binary.
Cómo Apple indexa las notas de la versión
Apple indexa texto a través de toda tu product page para determinar para qué búsquedas tu app es elegible. Los campos con mayor peso son tu título, subtítulo y campo de keywords. Debajo de esos, Apple procesa tu descripción, texto promocional y notas de la versión.
Las notas de la versión se reindexan en cada update. Eso significa que cada vez que shippeas, tienes una ventana fresca para introducir nuevos términos que reflejen lo que tu app hace ahora. Si shippeaste una nueva feature, la entrada de notas de la versión es el camino más rápido para conseguir que esa feature quede indexada antes de tu próxima submission completa de metadatos.
Esto importa para features que no existían al launch. Si añadiste soporte de dark mode, un widget, una share extension o un nuevo workflow desde que se escribieron tus metadatos originales, tu campo de keywords probablemente no menciona estas features en absoluto. Una entrada de notas de la versión que describe la nueva feature mete ese término en el índice de Apple inmediatamente.
Esto no es un loophole. Es usar la herramienta de la forma en que Apple la diseñó. El campo existe para que los developers comuniquen cambios. Apple indexa cambios porque le importan a los usuarios que buscan apps con funcionalidad específica.
El error específico que comete la mayoría de apps
Abre App Store Connect y mira tus últimas diez entradas de notas de la versión.
Si se ven así:
- “Bug Fixes”
- “Mejoras de performance”
- “Actualizaciones menores de estabilidad”
- “Hemos trabajado duro para mejorar tu experience”
No solo estás sirviendo mal a tus usuarios. Estás escribiendo contenido que es invisible para los sistemas de indexación de Apple.
“Bug Fixes” no contiene señal de keyword. “Mejoras de performance” no es un término de búsqueda que nadie escribe. “Trabajado duro para mejorar tu experience” es una frase de relleno que es filtrada por cualquier sistema de ranking que procese lenguaje natural.
Compara eso con:
Añadida integración de Focus Filter para que la lista de tu app se adapte a tu modo Focus actual. Mejoradas las sugerencias de keywords para mostrar el volumen de búsqueda mensual de cada término. Arreglado crash en iPad al abrir la vista de análisis de competidores con más de 50 apps trackeadas.
Esta versión nombra una feature específica (integración de Focus Filter), nombra términos de categoría que Apple puede indexar (sugerencias de keywords, volumen de búsqueda), describe un fix real con contexto de plataforma (crash en iPad) y contiene lenguaje natural que coincide con cómo los developers buscan funcionalidad.
Una de estas entradas trabaja para ti. La otra no.
Una fórmula que funciona
Escribe las notas de la versión en tres partes:
Lidera con la feature, nombrada específicamente. “Añadidos reportes de keywords programados” es indexable. “Mejoras a la sección de reportes” no lo es. Si shippeaste una nueva pantalla, nombra la pantalla. Si añadiste una integración, nombra el target de la integración. La especificidad es lo que se indexa, y la especificidad es también lo que los usuarios escanean cuando deciden si actualizar.
Nombra el caso de uso, no el mecanismo. “Sigue los cambios de keywords de competidores en 50 storefronts con digests diarios por email” es search-adjacent. “Optimización de backend para tracking de competidores” no lo es. Escribe desde la perspectiva del usuario, no la del engineer.
Describe los fixes con contexto. Los bug fixes pertenecen a las notas de la versión, pero deberían incluir qué estaba roto, en qué dispositivo o configuración, y cuál es el comportamiento esperado ahora. “Arreglado crash en iPhone SE al enviar metadatos con caracteres japoneses” es útil. “Crash arreglado” no lo es.
Bajo esta fórmula, una entrada de notas de la versión para un update sustancial podría verse así:
Añadida exportación CSV para el historial de rank de keywords. Ahora puedes exportar 90 días de datos de rank por keyword, por storefront, directamente desde la vista de tracking. La exportación se activa desde el ícono superior derecho en la pestaña de Keywords.
Mejorado el cálculo del ASO score para ponderar la frescura del texto promocional y la tasa de respuesta a reviews como señales separadas.
Arreglado el conteo incorrecto de caracteres mostrado en el editor del campo de keywords al usar locales de script mixto (japonés, coreano, chino).
Esta entrada tiene alrededor de 400 caracteres, bien dentro del límite de 4.000 caracteres, y contiene términos indexables a través de las categorías de metadatos y localización. Describe cambios reales que los usuarios pueden verificar, y le señala a Apple que el update fue sustancial.
Cómo se conectan las notas de la versión con el riesgo de purga 2026
El lenguaje de las guidelines de Apple — “not updated, improved, or does not attract customers” — aplica a apps ya publicadas. Tus notas de la versión son parte de la evidencia que Apple evalúa al valorar la recencia de updates.
Una app con notas de la versión descriptivas y específicas a features a lo largo de los últimos updates se lee de forma distinta para los sistemas de Apple que una app cuyo historial completo es “Bug fixes and performance improvements”. La primera demuestra desarrollo consistente y activo. La segunda no da señal en ninguna dirección, lo cual es casi tan malo como no tener updates en absoluto.
Si corriste la auditoría de metadatos del post anterior de esta serie, la recencia de updates fue uno de los seis checks. Notas de la versión sólidas son el mecanismo operativo detrás de ese check. No puedes reclamar “active development” con un update de binary si las notas de la versión no dicen nada sobre qué cambió.
Cada cuánto revisar tu estrategia de notas de la versión
Las notas de la versión están live hasta tu próximo update. Revísalas como parte de tu checklist estándar de pre-submission:
- Antes de shippear una feature significativa: redacta las notas de la versión junto con la feature, no después
- En releases de mantenimiento: describe lo que realmente cambió, aunque los cambios sean pequeños
- Después de un update mayor de plataforma (nueva versión de iOS, nuevo soporte de dispositivos): menciona la compatibilidad explícitamente en las notas
Sobre la frecuencia: Apple no publica un umbral de cada cuánto deben shippearse updates, pero el patrón que aparece en las advertencias de cuentas de developer sugiere que seis meses sin un update sustancial está en la ventana de riesgo. Releases consistentes con notas descriptivas a lo largo de una ventana móvil de 90 días dan evidencia más fuerte de mantenimiento que un único update grande cada ocho meses.
Qué puedes hacer antes de tu próxima submission
No puedes reescribir retroactivamente las notas de la versión pasadas. Pero cada update de aquí en adelante es una hoja en blanco.
Antes de tu próxima submission a App Store:
- Abre un borrador y lista cada cambio visible para el usuario en el build
- Para cada cambio, escribe una oración que nombre la feature y el caso de uso que aborda
- Para cada bug fix, añade la plataforma o el contexto afectado
- Combina todo en el campo de notas de la versión (300 a 500 caracteres suelen ser suficientes para una entrada sustancial; el límite de 4.000 caracteres te da espacio para profundizar si el update lo justifica)
Esto toma quince minutos. Es el metadato indexable más barato que producirás jamás, y se acumula con cada otra inversión de metadatos que hagas. Hazlo antes de tocar submit.
El optimizador de metadatos con AI de Marteso ayuda a redactar contenido consciente de keywords a través de todo tu listing. Si no has auditado tus metadatos actuales, marteso.com/aso-score-checker muestra exactamente dónde tu listing está underperformando — antes de tu próximo update.