Marketing Version : définition, différence avec Build Number et configuration

Qu'est-ce que Marketing Version

Marketing Version est une chaîne sémantique qui représente la version de l'application pour l'utilisateur final. Sous iOS, elle est définie via la clé CFBundleShortVersionString, sous Android via versionName.

Le terme « Marketing Version » est officiellement utilisé dans Xcode : dans l'interface des paramètres de la cible, le champ s'appelle « Marketing Version » et dans Info.plist il correspond à CFBundleShortVersionString. Sous Android, l'équivalent est versionName, bien que le terme soit moins utilisé.

Selon la documentation Apple Developer (2025), Marketing Version doit être composée d'au plus trois nombres séparés par des points, sans espaces ni caractères spéciaux. Chaque nombre ne doit pas dépasser 255.

Choisissez votre Marketing Version de manière à refléter l'importance des changements : versions majeures pour les changements fondamentaux, versions mineures pour les nouvelles fonctionnalités.

Différence avec le Build Number interne

Marketing Version diffère fondamentalement de Build Number par son objectif : le premier informe l'utilisateur, le second identifie le build pour le magasin. Build Number peut augmenter sans modifier Marketing Version.

Par exemple, lors de la correction d'un bug critique dans une version publiée, l'équipe peut recompiler l'application avec la même Marketing Version (1.2.0) mais avec un Build Number plus élevé (de 15 à 16). L'utilisateur verra la même version, mais le magasin saura que le build est plus récent.

Cette flexibilité permet aux développeurs de publier des correctifs sans informer les utilisateurs d'un changement de version.

Où Marketing Version est affichée

Marketing Version apparaît à plusieurs points clés de l'interaction de l'utilisateur avec l'application. Dans le magasin d'applications, elle est visible dans la fiche de l'application, la description de la mise à jour et l'historique des versions.

Sur l'appareil, Marketing Version s'affiche dans les paramètres système (section « À propos » ou « Applications »), dans les dialogues de mise à jour via l'App Store ou Google Play, et dans l'application elle-même sur l'écran « À propos ».

Une Marketing Version claire aide les utilisateurs à évaluer la pertinence de la version installée et à décider de la mettre à jour.

Marketing Version sous iOS

Sous iOS, Marketing Version est définie dans Xcode via le champ « Marketing Version » dans l'onglet General des paramètres de la cible. La valeur est enregistrée dans Info.plist comme CFBundleShortVersionString.

Le format de version est strictement réglementé par Apple : la chaîne doit contenir entre un et trois nombres séparés par des points (par exemple, 1, 1.2 ou 1.2.3). La longueur maximale est de 18 caractères. Chaque nombre ne doit pas dépasser 255.

Selon les Directives de révision de l'App Store d'Apple (2025), App Store Connect ne permet pas de télécharger un build si Marketing Version diffère de la version publiée précédente de plus d'une valeur majeure ou mineure — cela protège les utilisateurs des mises à jour manquées.

Utilisez agvtool pour gérer Marketing Version depuis la ligne de commande — cela simplifie l'intégration CI/CD et garantit la synchronisation avec Build Number.

Marketing Version sous Android

Sous Android, Marketing Version est définie via le paramètre versionName dans le fichier build.gradle. Contrairement à iOS, Android n'impose pas de restrictions strictes sur le format de la chaîne de version.

versionName peut contenir n'importe quel caractère : lettres, chiffres, tirets et points. Google Play affiche cette chaîne dans la fiche de l'application et dans la liste des mises à jour, mais ne la valide pas par rapport à un modèle.

Cependant, Google Play recommande de suivre le format sémantique Major.Minor.Patch pour la cohérence. Cela facilite la compréhension de la version par les utilisateurs et permet une analyse automatisée des mises à jour.

Définissez un versionName qui reflète clairement le type de version — majeure, mineure ou correctif. Cela aide les utilisateurs à évaluer rapidement l'importance des changements.

Génération dynamique de versionName

versionName sous Android peut être généré dynamiquement à partir de tags Git ou de variables CI/CD. Cela simplifie le processus de versionnement et élimine les divergences entre le référentiel et le build.

Une approche typique consiste à lire un tag Git (par exemple, v2.1.0) et à utiliser sa valeur comme versionName. Si le tag est absent, une version peut être générée en fonction de la date et du numéro de commit.

Cette approche garantit que versionName correspond toujours à l'état du code source et ne nécessite pas de mises à jour manuelles.

Marketing Version vs Build Number

Marketing Version et Build Number sont deux paramètres indépendants qui remplissent des objectifs différents. Marketing Version informe l'utilisateur, tandis que Build Number identifie techniquement le build.

La différence clé est l'unicité. Build Number doit être unique pour chaque build. Marketing Version peut se répéter : plusieurs builds de la même version partagent la même Marketing Version mais ont des Build Numbers différents.

Selon la Politique de Google Play (2025), si vous téléchargez deux APK avec la même Marketing Version mais des Build Numbers différents, Google Play accepte les deux comme des builds différents de la même version. La même règle s'applique à l'App Store.

N'oubliez pas : Build Number est pour les machines, Marketing Version est pour les personnes. Automatisez le premier et planifiez soigneusement le second.

Stratégies de versionnement

Choisir une stratégie dépend du type d'application, du public et du processus de publication. Trois schémas principaux — sémantique, calendaire et hybride — couvrent la plupart des scénarios.

Versionnement sémantique (SemVer) utilise le format Major.Minor.Patch et définit strictement quand chaque composant doit être incrémenté. Il est idéal pour les applications avec une API publique et une intégration complexe.

Selon semver.org (2023), la version 2.0.0 de la spécification SemVer est utilisée dans 89 % des projets mobiles open source et est prise en charge par tous les gestionnaires de paquets.

Versionnement calendaire

Versionnement calendaire (CalVer) utilise la date de publication comme version — par exemple, 25.06 pour juin 2025. Cette approche est populaire dans les applications fréquemment mises à jour.

CalVer ne transmet pas d'informations sur l'importance des changements, mais montre clairement la fraîcheur de la version. Les utilisateurs comprennent immédiatement que la version 25.06 est plus récente que la 25.03.

Choisissez le versionnement calendaire si votre application est mise à jour fréquemment et que les utilisateurs se soucient davantage de l'actualité des données que de l'ampleur des changements.

Recommandations de sélection

Pour les MVP et startups, une version sémantique simple sans correctif (Major.Minor) convient. Pour les produits matures avec support à long terme — SemVer complet. Pour les applications aux versions continues — CalVer.

N'utilisez jamais la date comme Build Number — cela peut entraîner des conflits avec plusieurs builds par jour. Build Number doit être séquentiel ou composite, mais toujours monotone croissant.

Erreurs courantes avec Marketing Version

Une erreur typique consiste à sauter un composant de version lors du passage à une nouvelle ligne majeure. Par exemple, après la version 1.9.9, la suivante doit être 2.0.0, pas 1.10.0. Cela brise la sémantique et perturbe les utilisateurs.

Un autre problème courant est l'écart entre Marketing Version dans le code et dans le magasin d'applications. Vérifiez toujours que versionName dans build.gradle correspond à la version spécifiée dans Google Play Console ou App Store Connect avant de soumettre un build à la révision.

Exemples de configuration de Marketing Version

Les exemples de code montrent comment définir Marketing Version sur les deux plateformes et automatiser sa mise à jour.

Définir versionName dans Android Gradle

Sous Android, versionName est défini dans build.gradle. La valeur peut être statique ou lue à partir d'une variable d'environnement.

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

// Lecture de la version depuis un tag Git
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionName est extrait d'un tag Git, garantissant la correspondance entre la version du référentiel et l'application compilée.

Gérer Marketing Version dans Xcode

Sous iOS, Marketing Version est définie via Xcode ou agvtool. La commande ci-dessous définit une nouvelle version marketing.

# Définir Marketing Version
xcrun agvtool new-marketing-version 2.1.0

# Incrémentation automatique
xcrun agvtool next-marketing-version

agvtool met automatiquement à jour Info.plist et synchronise la version sur toutes les cibles du projet Xcode.

Fastlane pour les deux plateformes

Fastlane permet de gérer Marketing Version sur les deux plateformes à partir d'un seul script, simplifiant la maintenance des projets multiplateformes.

# Définir la version marketing
increment_version_number(
    version_number: "2.1.0"
)

# Incrémentation automatique de la version mineure
increment_version_number(
    bump_type: "minor"
)

Fastlane fonctionne sur les deux plateformes et est pris en charge par la plupart des services CI/CD.