Marketing Version: qué es, diferencia con Build Number y configuración

Qué es Marketing Version

Marketing Version es una cadena semántica que representa la versión de la aplicación para el usuario final. En iOS se define mediante la clave CFBundleShortVersionString, en Android mediante versionName.

El término “Marketing Version” se usa oficialmente en Xcode: en la interfaz de configuración del target, el campo se llama “Marketing Version” y en Info.plist corresponde a CFBundleShortVersionString. En Android el equivalente es versionName, aunque el término se usa con menos frecuencia.

Según la Documentación de Apple Developer (2025), Marketing Version debe constar de un máximo de tres números separados por puntos, sin espacios ni caracteres especiales. Cada número no debe superar 255.

Elige tu Marketing Version de modo que refleje la importancia de los cambios: versiones mayores para cambios fundamentales, versiones menores para nuevas funcionalidades.

Diferencia con el Build Number interno

Marketing Version se diferencia fundamentalmente de Build Number en su propósito: el primero informa al usuario, el segundo identifica la compilación para la tienda. Build Number puede aumentar sin cambiar Marketing Version.

Por ejemplo, al corregir un error crítico en una versión publicada, el equipo puede recompilar la aplicación con la misma Marketing Version (1.2.0) pero con un Build Number mayor (de 15 a 16). El usuario verá la misma versión, pero la tienda sabrá que la compilación es más reciente.

Esta flexibilidad permite a los desarrolladores lanzar correcciones sin notificar a los usuarios sobre un cambio de versión.

Dónde se muestra Marketing Version

Marketing Version aparece en varios puntos clave de interacción del usuario con la aplicación. En la tienda de aplicaciones, es visible en la ficha de la aplicación, en la descripción de la actualización y en el historial de versiones.

En el dispositivo, Marketing Version se muestra en los ajustes del sistema (sección “Acerca de” o “Aplicaciones”), en los diálogos de actualización de App Store o Google Play, y dentro de la propia aplicación en la pantalla “Acerca de”.

Una Marketing Version clara ayuda a los usuarios a evaluar la relevancia de la versión instalada y a decidir si actualizar.

Marketing Version en iOS

En iOS, Marketing Version se configura en Xcode mediante el campo “Marketing Version” en la pestaña General de los ajustes del target. El valor se guarda en Info.plist como CFBundleShortVersionString.

El formato de versión está estrictamente regulado por Apple: la cadena debe contener entre uno y tres números separados por puntos (por ejemplo, 1, 1.2 o 1.2.3). La longitud máxima es de 18 caracteres. Cada número no debe superar 255.

Según las Directrices de revisión de App Store de Apple (2025), App Store Connect no permite subir una compilación si Marketing Version difiere de la versión publicada anterior en más de un valor mayor o menor: esto protege a los usuarios de actualizaciones omitidas.

Usa agvtool para gestionar Marketing Version desde la línea de comandos: simplifica la integración con CI/CD y garantiza la sincronización con Build Number.

Marketing Version en Android

En Android, Marketing Version se define mediante el parámetro versionName en el archivo build.gradle. A diferencia de iOS, Android no impone restricciones estrictas sobre el formato de la cadena de versión.

versionName puede contener cualquier carácter: letras, dígitos, guiones y puntos. Google Play muestra esta cadena en la ficha de la aplicación y en la lista de actualizaciones, pero no la valida contra ningún patrón.

Sin embargo, Google Play recomienda seguir el formato semántico Major.Minor.Patch para mantener la coherencia. Esto facilita la comprensión de la versión por parte de los usuarios y permite automatizar el análisis de actualizaciones.

Define un versionName que refleje claramente el tipo de versión: mayor, menor o parche. Esto ayuda a los usuarios a evaluar rápidamente la importancia de los cambios.

Generación dinámica de versionName

versionName en Android puede generarse dinámicamente a partir de etiquetas Git o variables de CI/CD. Esto simplifica el proceso de versionado y elimina discrepancias entre el repositorio y la compilación.

Un enfoque típico consiste en leer una etiqueta Git (por ejemplo, v2.1.0) y usar su valor como versionName. Si no hay etiqueta, se puede generar una versión basada en la fecha y el número de commit.

Este enfoque garantiza que versionName siempre coincida con el estado del código fuente y no requiera actualizaciones manuales.

Marketing Version vs Build Number

Marketing Version y Build Number son dos parámetros independientes que cumplen funciones distintas. Marketing Version informa al usuario, mientras que Build Number identifica técnicamente la compilación.

La diferencia clave es la unicidad. Build Number debe ser único para cada compilación. Marketing Version puede repetirse: varias compilaciones de la misma versión comparten la misma Marketing Version pero tienen diferentes Build Numbers.

Según la Política de Google Play (2025), si subes dos APK con la misma Marketing Version pero diferentes Build Numbers, Google Play acepta ambas como compilaciones distintas de la misma versión. La misma regla aplica para App Store.

Recuerda: Build Number es para máquinas, Marketing Version es para personas. Automatiza el primero y planifica cuidadosamente la segunda.

Estrategias de versionado

Elegir una estrategia depende del tipo de aplicación, la audiencia y el proceso de lanzamiento. Tres esquemas principales —semántico, calendario e híbrido— cubren la mayoría de los escenarios.

Versionado Semántico (SemVer) usa el formato Major.Minor.Patch y define estrictamente cuándo incrementar cada componente. Es ideal para aplicaciones con API pública e integración compleja.

Según semver.org (2023), la versión 2.0.0 de la especificación SemVer se usa en el 89% de los proyectos móviles de código abierto y es compatible con todos los gestores de paquetes.

Versionado por calendario

Versionado por calendario (CalVer) usa la fecha de lanzamiento como versión —por ejemplo, 25.06 para junio de 2025. Este enfoque es popular en aplicaciones con actualizaciones frecuentes.

CalVer no transmite información sobre la importancia de los cambios, pero muestra claramente la actualidad de la versión. Los usuarios entienden de inmediato que la versión 25.06 es más reciente que la 25.03.

Elige el versionado por calendario si tu aplicación se actualiza con frecuencia y a los usuarios les importa más la actualidad de los datos que el alcance de los cambios.

Recomendaciones de selección

Para MVP y startups, una versión semántica simple sin parche (Major.Minor) funciona bien. Para productos maduros con soporte a largo plazo —SemVer completo. Para aplicaciones con lanzamientos continuos —CalVer.

Nunca uses la fecha como Build Number —esto puede provocar conflictos con múltiples compilaciones al día. Build Number debe ser secuencial o compuesto, pero siempre monótonamente creciente.

Errores comunes en Marketing Version

Un error típico es saltarse un componente de versión al pasar a una nueva línea mayor. Por ejemplo, después de la versión 1.9.9, la siguiente debería ser 2.0.0, no 1.10.0. Esto rompe la semántica y confunde a los usuarios.

Otro problema frecuente es la discrepancia entre Marketing Version en el código y en la tienda de aplicaciones. Verifica siempre que versionName en build.gradle coincida con la versión especificada en Google Play Console o App Store Connect antes de enviar una compilación a revisión.

Ejemplos de configuración de Marketing Version

Los ejemplos de código muestran cómo definir Marketing Version en ambas plataformas y automatizar su actualización.

Configuración de versionName en Android Gradle

En Android, versionName se define en build.gradle. El valor puede ser estático o leerse de una variable de entorno.

android {
    defaultConfig {
        versionCode 15
        versionName "2.1.0"
    }
}

// Lectura de versión desde etiqueta Git
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionName se extrae de una etiqueta Git, lo que garantiza la coherencia entre la versión en el repositorio y la aplicación compilada.

Gestión de Marketing Version en Xcode

En iOS, Marketing Version se configura a través de Xcode o agvtool. El siguiente comando establece una nueva versión de marketing.

# Configurar Marketing Version
xcrun agvtool new-marketing-version 2.1.0

# Incremento automático
xcrun agvtool next-marketing-version

agvtool actualiza automáticamente Info.plist y sincroniza la versión en todos los targets del proyecto Xcode.

Fastlane para ambas plataformas

Fastlane permite gestionar Marketing Version en ambas plataformas desde un solo script, simplificando el mantenimiento de proyectos multiplataforma.

# Configurar versión de marketing
increment_version_number(
    version_number: "2.1.0"
)

# Incremento automático de versión menor
increment_version_number(
    bump_type: "minor"
)

Fastlane funciona en ambas plataformas y es compatible con la mayoría de servicios CI/CD.