Gestiona el versionado de tus apps

El versionado semántico es la convención muy extendida de escribir tu nombre de versión en tres números, mayor.menor.parche, donde cada posición señala el tamaño del cambio. Aumentas el número mayor para cambios grandes o rupturistas y rediseños, el número menor para nuevas funciones que no rompen el comportamiento existente, y el número de parche para correcciones de errores y pequeños ajustes. Así, 2.4.1 significa versión mayor 2, la cuarta publicación de funciones en esa línea, con un parche encima. Es una convención, no una regla de las tiendas, pero adoptarla hace tu historial legible de un vistazo y ayuda a todo el equipo a ponerse de acuerdo sobre lo que contiene una publicación antes de sacarla.

• Mayor (el primer número): cambios rupturistas, rediseños importantes o una nueva versión de pago. Ejemplo: 1.9.0 pasa a 2.0.0.
• Menor (el número del medio): nuevas funciones retrocompatibles. Ejemplo: 2.3.4 pasa a 2.4.0.
• Parche (el último número): correcciones de errores y arreglos menores sin funciones nuevas. Ejemplo: 2.4.0 pasa a 2.4.1.

Un hábito que conviene mantener: reinicia los números inferiores cuando cambia uno superior. Cuando subes el número menor, el parche vuelve a 0, y cuando subes el mayor, tanto el menor como el parche vuelven a 0. Eso es lo que hace que 3.0.0 se lea como una línea nueva y limpia en lugar de un 3.4.7 salido de la nada.

En iOS, el nombre de versión vive en un campo llamado CFBundleShortVersionString, que App Store Connect y Xcode etiquetan simplemente como Version. Es el número público de estilo 2.4.1 que ven tus usuarios. El número de build vive en un campo aparte llamado CFBundleVersion, etiquetado como Build. Apple exige que dentro de un mismo nombre de versión, cada nueva build que subas tenga un número de build mayor, y acepta varios formatos comunes como un entero simple o una forma con puntos como 1043 o 1.0.43. Cuando envías una nueva versión a revisión, eliges la build concreta que le adjuntas. Un detalle útil: una vez que un nombre de versión se ha publicado en la App Store, no puedes reutilizarlo para otra publicación, así que trata tus nombres de versión publicados como definitivos.

En Android, el nombre de versión se llama versionName y se comporta como el campo Version de iOS: es tu cadena pública 2.4.1 y puede ser lo que quieras. El número de build se llama versionCode, y aquí es donde Android es más estricto que iOS. El versionCode debe ser un entero positivo, sin puntos, y debe aumentar siempre con cada build que subas a un canal dado de Google Play. Google Play usa solo el versionCode para decidir qué build es más nueva, así que una build con un versionCode más alto siempre se trata como la actualización. Si olvidas subirlo, la Play Console rechaza la subida sin más. Como es un entero, los equipos suelen derivarlo de un contador de build o de una fecha, pero el único requisito estricto es que nunca retroceda.

• versionName: la cadena pública, por ejemplo 2.4.1. Se muestra a los usuarios, libre, no tiene que ser numérica.
• versionCode: un entero positivo, por ejemplo 1043. Nunca se muestra a los usuarios, debe aumentar estrictamente, y es como Google Play ordena las builds.
• Ambos viven en tu configuración de build (build.gradle para Android nativo, o pubspec.yaml para Flutter, donde el formato es versionName+versionCode, como 2.4.1+1043).

Mantener el nombre de versión idéntico en ambas plataformas es un buen hábito que compensa constantemente. Cuando un usuario reporta un error en 2.4.1, quieres que eso signifique la misma publicación en iOS y Android, no dos estados de código distintos. Cuando tu equipo de soporte, tu changelog y tus analíticas se apoyan en un solo nombre de versión, la depuración multiplataforma se vuelve muchísimo más sencilla. Los números de build, en cambio, no necesitan coincidir, porque iOS y Android los incrementan de forma independiente y las tiendas nunca los comparan. Así que la regla práctica es: comparte el nombre de versión de marketing entre ambas tiendas, y deja que cada plataforma gestione su propio número de build. Si compilas con Flutter o React Native desde una sola base de código, ya estás produciendo ambas apps desde la misma fuente, lo que hace de un nombre de versión compartido la opción natural por defecto.

Las notas de versión, a menudo llamadas el texto de Novedades, son la breve descripción adjunta a cada versión que explica lo que cambió. Ambas tiendas las muestran en la ficha y en la pantalla de actualización, así que se leen mucho más de lo que los desarrolladores suponen. Las buenas notas son concretas y orientadas al usuario: describen lo que la persona obtiene o lo que se corrigió, no números de tickets internos ni refactorizaciones. Empieza por el cambio que los usuarios notarán más, mantén cada línea corta, y evita el relleno genérico del tipo corrección de errores y mejoras de rendimiento cuando de verdad tienes algo concreto que decir. Como ambas tiendas admiten notas de versión localizadas, traducirlas para tus mercados principales es una forma barata de hacer que una actualización se sienta cuidada en vez de publicada y olvidada.

1. Abre con el cambio estrella, la única cosa que más importará a los usuarios.
2. Enumera las incorporaciones o correcciones notables en lenguaje claro, una por línea.
3. Iguala el tono entre iOS y Android para que el usuario vea la misma historia en ambas.
4. Localiza las notas para tus principales mercados, igual que localizas la ficha.
5. Mantén también un changelog interno, para que la versión 2.4.1 siempre corresponda a un conjunto conocido de commits.

Ambas tiendas te permiten publicar una nueva versión a una parte de tus usuarios primero, y luego ampliarla, para que una mala build no llegue a todos a la vez. En Google Play esto se llama despliegue escalonado: eliges un porcentaje, por ejemplo el 10 por ciento, y Google entrega la actualización a esa parte de usuarios, dejándote aumentar el porcentaje o detener el despliegue si las tasas de fallos se disparan. En la App Store el equivalente es la publicación por fases, que despliega automáticamente una actualización automática a lo largo de una ventana de siete días en pasos crecientes, con opción de pausar. En ambos casos los usuarios aún pueden obtener la última versión de inmediato si actualizan manualmente desde la tienda, así que un despliegue por fases ralentiza las actualizaciones automáticas en lugar de ocultar la publicación. Para cualquier actualización que toque código arriesgado, activarlo te da una válvula de seguridad.

La mayor parte del dolor de versionado viene de una corta lista de errores evitables, y casi todos aparecen al momento de subir, cuando menos quieres ese retraso. Conocerlos por adelantado te ahorra una build rechazada durante una publicación que intentabas sacar rápido.

• Olvidar subir el versionCode de Android, de modo que Google Play rechaza el .aab porque el número ya existe. Es el bloqueo número uno el día de la publicación.
• Reutilizar un número de build de iOS bajo el mismo nombre de versión, algo que App Store Connect rechaza de la misma manera.
• Dejar que los nombres de versión de iOS y Android se separen, de modo que 2.4.1 en iOS no es el mismo código que 2.4.1 en Android y los reportes de errores se vuelven ambiguos.
• Editar las versiones a mano en el archivo de build y olvidar una plataforma, algo fácil cuando los dos números viven en archivos distintos.
• Publicar un nombre de versión que retrocede o da saltos, algo que las tiendas no bloquean pero que confunde a los usuarios y a tu propio changelog.

La solución fiable es hacer que la subida de versión forme parte de tu proceso de publicación en lugar de algo que recuerdas a mano. Ya sea que lo automatices en CI o lo gestiones en una plataforma de publicación, el objetivo es que el nombre de versión correcto y un número de build siempre creciente se definan de la misma forma cada vez, para ambas tiendas, para que una subida rechazada nunca te cueste una hora el día de la publicación. Si compilas multiplataforma, mira cómo funciona el lado iOS de ese pipeline para Flutter y para React Native.

versionName es la cadena pública que ven los usuarios, como 2.4.1, y puede ser cualquier cosa. versionCode es un entero positivo, como 1043, que los usuarios nunca ven y que Google Play usa para decidir qué build es más nueva. El versionCode debe aumentar con cada subida, mientras que el versionName puede repetirse o seguir cualquier esquema que elijas. Son los equivalentes en Android de los campos Version y Build de iOS.

No, no dentro del mismo canal de tienda. En Google Play el versionCode debe ser estrictamente mayor que la subida anterior, y en la App Store el número de build debe ser mayor dentro de un nombre de versión dado. Puedes mantener el nombre de versión público igual en varias builds, por ejemplo al corregir un rechazo de revisión, pero cada una de esas builds necesita su propio número de build superior para ser aceptada.

Las tiendas no lo exigen, y nunca comparan las dos plataformas. Hacer coincidir el nombre de versión público entre iOS y Android es una convención fuerte porque hace que los reportes de errores, las analíticas y el soporte sean inequívocos. Los números de build, en cambio, se gestionan de forma independiente por plataforma y no necesitan coincidir, ya que cada tienda lleva su propio contador y nunca mira el de la otra.

No puedes retirar de verdad una versión, ya que ninguna tienda te deja reemplazar una build publicada por código más antiguo bajo el mismo nombre de versión. Si lo detectaste durante un despliegue escalonado o por fases, detén el despliegue para que nuevos usuarios no lo obtengan. Luego corrige el error y publica una nueva versión superior. Por eso importa una subida de versión rápida y correcta: tu camino de recuperación siempre va hacia adelante, nunca hacia atrás. Versionar de la misma forma tus documentos legales y metadatos de tienda evita sorpresas similares.