Marketing Version: Was es ist, Unterschied zur Build Number und Konfiguration

Was ist Marketing Version

Marketing Version ist eine semantische Zeichenfolge, die die Anwendungsversion für den Endbenutzer darstellt. Unter iOS wird sie über den Schlüssel CFBundleShortVersionString festgelegt, unter Android über versionName.

Der Begriff „Marketing Version“ wird offiziell in Xcode verwendet: In der Benutzeroberfläche der Target-Einstellungen heißt das Feld „Marketing Version“ und in Info.plist entspricht es CFBundleShortVersionString. Unter Android ist das Äquivalent versionName, auch wenn der Begriff seltener verwendet wird.

Laut der Apple Developer-Dokumentation (2025) muss die Marketing Version aus maximal drei durch Punkte getrennten Zahlen bestehen, ohne Leerzeichen oder Sonderzeichen. Jede Zahl darf 255 nicht überschreiten.

Wählen Sie Ihre Marketing Version so, dass sie die Bedeutung der Änderungen widerspiegelt: Hauptversionen für grundlegende Änderungen, Nebenversionen für neue Funktionalitäten.

Unterschied zur internen Build Number

Marketing Version unterscheidet sich grundlegend von der Build Number im Zweck: Erstere informiert den Benutzer, Letztere identifiziert den Build für den Store. Die Build Number kann erhöht werden, ohne die Marketing Version zu ändern.

Zum Beispiel beim Beheben eines kritischen Fehlers in einem veröffentlichten Release kann das Team die Anwendung mit derselben Marketing Version (1.2.0) aber einer erhöhten Build Number (von 15 auf 16) neu erstellen. Der Benutzer sieht dieselbe Version, aber der Store weiß, dass der Build neuer ist.

Diese Flexibilität ermöglicht es Entwicklern, Korrekturen zu veröffentlichen, ohne Benutzer über eine Versionsänderung zu informieren.

Wo wird die Marketing Version angezeigt

Marketing Version erscheint an mehreren wichtigen Berührungspunkten der Benutzerinteraktion mit der Anwendung. Im App Store ist sie in der App-Karte, in der Update-Beschreibung und im Versionsverlauf sichtbar.

Auf dem Gerät wird die Marketing Version in den Systemeinstellungen (Bereich „Über“ oder „Apps“), in Update-Dialogen über den App Store oder Google Play sowie in der App selbst auf dem Bildschirm „Über“ angezeigt.

Eine klare Marketing Version hilft Benutzern, die Aktualität der installierten Version zu bewerten und eine Update-Entscheidung zu treffen.

Marketing Version unter iOS

Unter iOS wird die Marketing Version in Xcode über das Feld „Marketing Version“ auf der Registerkarte „General“ der Target-Einstellungen festgelegt. Der Wert wird in Info.plist als CFBundleShortVersionString gespeichert.

Das Versionsformat ist von Apple streng reguliert: Die Zeichenfolge muss ein bis drei durch Punkte getrennte Zahlen enthalten (z. B. 1, 1.2 oder 1.2.3). Die maximale Länge beträgt 18 Zeichen. Jede Zahl darf 255 nicht überschreiten.

Laut den Apple App Store Review Guidelines (2025) erlaubt App Store Connect das Hochladen eines Builds nicht, wenn die Marketing Version um mehr als einen Haupt- oder Nebenwert von der vorherigen veröffentlichten Version abweicht — dies schützt Benutzer vor verpassten Updates.

Verwenden Sie agvtool zur Verwaltung der Marketing Version über die Befehlszeile — es vereinfacht die CI/CD-Integration und gewährleistet die Synchronisation mit der Build Number.

Marketing Version unter Android

Unter Android wird die Marketing Version über den Parameter versionName in der Datei build.gradle festgelegt. Im Gegensatz zu iOS erzwingt Android keine strengen Einschränkungen für das Format der Versionszeichenfolge.

versionName kann beliebige Zeichen enthalten: Buchstaben, Ziffern, Bindestriche und Punkte. Google Play zeigt diese Zeichenfolge in der App-Karte und in der Update-Liste an, validiert sie aber nicht gegen ein bestimmtes Muster.

Allerdings empfiehlt Google Play, zur Vereinheitlichung das semantische Major.Minor.Patch-Format zu verwenden. Dies erleichtert Benutzern das Verständnis der Version und ermöglicht eine automatisierte Update-Analyse.

Legen Sie einen versionName fest, der klar den Release-Typ widerspiegelt — Hauptversion, Nebenversion oder Patch. Dies hilft Benutzern, die Bedeutung von Änderungen schnell einzuschätzen.

Dynamische Generierung von versionName

versionName unter Android kann dynamisch auf der Grundlage von Git-Tags oder CI/CD-Variablen generiert werden. Dies vereinfacht den Versionierungsprozess und beseitigt Diskrepanzen zwischen Repository und Build.

Ein typischer Ansatz ist das Auslesen eines Git-Tags (z. B. v2.1.0) und die Verwendung seines Werts als versionName. Wenn kein Tag vorhanden ist, kann eine Version basierend auf Datum und Commit-Nummer generiert werden.

Dieser Ansatz stellt sicher, dass versionName immer mit dem Zustand des Quellcodes übereinstimmt und keine manuellen Aktualisierungen erfordert.

Marketing Version vs. Build Number

Marketing Version und Build Number sind zwei unabhängige Parameter, die unterschiedliche Zwecke erfüllen. Die Marketing Version informiert den Benutzer, während die Build Number den Build technisch identifiziert.

Der Hauptunterschied ist die Eindeutigkeit. Die Build Number muss für jeden Build eindeutig sein. Die Marketing Version kann wiederholt werden: Mehrere Builds derselben Version teilen sich dieselbe Marketing Version, haben aber unterschiedliche Build Numbers.

Laut Google Play-Richtlinie (2025) akzeptiert Google Play, wenn Sie zwei APKs mit derselben Marketing Version aber unterschiedlichen Build Numbers hochladen, beide als unterschiedliche Builds derselben Version. Für den App Store gilt die gleiche Regel.

Denken Sie daran: Build Number ist für Maschinen, Marketing Version ist für Menschen. Automatisieren Sie Ersteres und planen Sie Letzteres sorgfältig.

Versionierungsstrategien

Die Wahl einer Strategie hängt vom Anwendungstyp, der Zielgruppe und dem Release-Prozess ab. Drei Hauptschemata — semantisch, Kalender und hybrid — decken die meisten Szenarien ab.

Semantische Versionierung (SemVer) verwendet das Major.Minor.Patch-Format und definiert streng, wann jede Komponente erhöht werden muss. Sie ist ideal für Anwendungen mit öffentlicher API und komplexer Integration.

Laut semver.org (2023) wird Version 2.0.0 der SemVer-Spezifikation in 89% der Open-Source-Mobilprojekte verwendet und von allen Paketmanagern unterstützt.

Kalender-Versionierung

Kalender-Versionierung (CalVer) verwendet das Veröffentlichungsdatum als Version — z. B. 25.06 für Juni 2025. Dieser Ansatz ist bei häufig aktualisierten Anwendungen beliebt.

CalVer enthält keine Informationen über die Bedeutung von Änderungen, zeigt aber deutlich die Aktualität der Version. Benutzer verstehen sofort, dass Version 25.06 neuer ist als 25.03.

Wählen Sie Kalender-Versionierung, wenn Ihre App häufig aktualisiert wird und Benutzern die Aktualität der Daten wichtiger ist als der Umfang der Änderungen.

Auswahlempfehlungen

Für MVPs und Startups ist eine einfache semantische Version ohne Patch (Major.Minor) geeignet. Für ausgereifte Produkte mit langfristigem Support — vollständiges SemVer. Für Apps mit kontinuierlichen Releases — CalVer.

Verwenden Sie niemals das Datum als Build Number — dies kann bei mehreren Builds pro Tag zu Konflikten führen. Die Build Number sollte sequentiell oder zusammengesetzt sein, aber immer monoton steigend.

Häufige Fehler bei der Marketing Version

Ein typischer Fehler ist das Überspringen einer Versionskomponente beim Wechsel zu einer neuen Hauptversionslinie. Nach Version 1.9.9 sollte beispielsweise 2.0.0 kommen, nicht 1.10.0. Dies bricht die Semantik und verwirrt Benutzer.

Ein weiteres häufiges Problem ist die Diskrepanz zwischen der Marketing Version im Code und im App Store. Überprüfen Sie immer, ob versionName in build.gradle mit der in Google Play Console oder App Store Connect angegebenen Version übereinstimmt, bevor Sie einen Build zur Überprüfung einreichen.

Einrichtungsbeispiele für Marketing Version

Codebeispiele zeigen, wie die Marketing Version auf beiden Plattformen festgelegt und ihre Aktualisierung automatisiert wird.

versionName in Android Gradle festlegen

Unter Android wird versionName in build.gradle festgelegt. Der Wert kann statisch sein oder aus einer Umgebungsvariable gelesen werden.

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

// Version aus Git-Tag lesen
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionName wird aus einem Git-Tag extrahiert, was die Übereinstimmung zwischen der Repository-Version und der erstellten Anwendung gewährleistet.

Verwalten der Marketing Version in Xcode

Unter iOS wird die Marketing Version über Xcode oder agvtool festgelegt. Der folgende Befehl legt eine neue Marketing-Version fest.

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

# Automatische Erhöhung
xcrun agvtool next-marketing-version

agvtool aktualisiert automatisch Info.plist und synchronisiert die Version über alle Xcode-Projekt-Targets hinweg.

Fastlane für beide Plattformen

Fastlane ermöglicht die Verwaltung der Marketing Version auf beiden Plattformen über ein einziges Skript, was die Wartung plattformübergreifender Projekte vereinfacht.

# Marketing-Version festlegen
increment_version_number(
    version_number: "2.1.0"
)

# Automatische Erhöhung der Nebenversion
increment_version_number(
    bump_type: "minor"
)

Fastlane funktioniert auf beiden Plattformen und wird von den meisten CI/CD-Diensten unterstützt.