Marketing Version: wat is het, verschil met Build Number en instellen

Wat is Marketing Version

Marketing Version — is een semantische tekenreeks die de versie van de app voor de eindgebruiker weergeeft. In iOS wordt dit ingesteld met de sleutel CFBundleShortVersionString, in Android met de parameter versionName.

De term „Marketing Version" wordt officieel gebruikt in Xcode: in de target-instellingeninterface heet het veld „Marketing Version" en in Info.plist komt het overeen met CFBundleShortVersionString. In Android is de tegenhanger versionName, hoewel de term minder vaak wordt gebruikt.

Volgens Apple Developer Documentation (2025) moet Marketing Version uit maximaal drie cijfers bestaan, gescheiden door punten, zonder spaties en speciale tekens. Elk cijfer mag niet hoger zijn dan 255.

Kies Marketing Version zo dat het de belangrijkheid van wijzigingen weerspiegelt: major-updates voor ingrijpende wijzigingen, minor-updates voor nieuwe functionaliteit.

Verschil met interne Build Number

Marketing Version verschilt fundamenteel van Build Number in doel: de eerste informeert de gebruiker, de tweede identificeert de build voor de winkel. Build Number kan toenemen zonder Marketing Version te wijzigen.

Tijdens het corrigeren van een kritieke fout in een uitgebrachte release kan het team bijvoorbeeld de app herbouwen met dezelfde Marketing Version (1.2.0) maar met verhoogde Build Number (van 15 naar 16). De gebruiker ziet dezelfde versie, maar de winkel begrijpt dat de build nieuwer is.

Deze flexibiliteit stelt ontwikkelaars in staat correcties uit te brengen zonder gebruikers te informeren over een versiewijziging.

Waar wordt Marketing Version weergegeven

Marketing Version wordt weergegeven op verschillende belangrijke interactiepunten van de gebruiker met de app. In de appstore is het zichtbaar in de app-kaart, in de updatebeschrijving en in de versiegeschiedenis.

Op het apparaat wordt Marketing Version getoond in systeeminstellingen (sectie „Over app" of „Apps"), in updatedialogen via App Store of Google Play, en ook in de app zelf op het scherm „Over".

Een begrijpelijke Marketing Version helpt de gebruiker de actualiteit van de geïnstalleerde versie te beoordelen en een beslissing te nemen over een update.

Marketing Version op iOS

Op iOS wordt Marketing Version ingesteld in Xcode via het veld „Marketing Version" op het tabblad General van de target-instellingen. De waarde wordt opgeslagen in Info.plist als CFBundleShortVersionString.

Het versieformaat wordt strikt gereguleerd door Apple: de tekenreeks moet één tot drie door punten gescheiden cijfers bevatten (bijv. 1, 1.2 of 1.2.3). Maximale lengte — 18 tekens. Elk cijfer is niet hoger dan 255.

Volgens Apple App Store Review Guidelines (2025) staat App Store Connect niet toe een build te uploaden als Marketing Version meer dan één major- of minorwaarde verschilt van de vorige gepubliceerde versie — dit beschermt gebruikers tegen gemiste updates.

Gebruik agvtool voor het beheren van Marketing Version vanaf de opdrachtregel — dit vereenvoudigt integratie met CI/CD-systemen en garandeert synchronisatie met Build Number.

Marketing Version op Android

Op Android wordt Marketing Version ingesteld met de parameter versionName in het bestand build.gradle. In tegenstelling tot iOS legt Android geen strikte beperkingen op aan het formaat van de versietekenreeks.

versionName kan alle tekens bevatten: letters, cijfers, koppeltekens en punten. Google Play toont deze tekenreeks in de app-kaart en in de updatelijst, maar controleert niet op conformiteit met een sjabloon.

Echter Google Play beveelt aan het semantische formaat Major.Minor.Patch aan te houden voor uniformiteit. Dit vereenvoudigt de perceptie van de versie door gebruikers en maakt geautomatiseerde analyse van updates mogelijk.

Specificeer een versionName dat duidelijk het releasetype weerspiegelt — major-update, minor of patch. Dit helpt gebruikers snel de belangrijkheid van wijzigingen te beoordelen.

Dynamische generatie van versionName

versionName op Android kan dynamisch worden gegenereerd op basis van Git-tags of CI/CD-variabelen. Dit vereenvoudigt het versiebeheerproces en elimineert discrepanties tussen repository en build.

Typische aanpak — het lezen van een Git-tag (bijv. v2.1.0) en het gebruik van de waarde als versionName. Als er geen tag is, kan een versie worden gegenereerd op basis van datum en commitnummer.

Deze aanpak garandeert dat versionName altijd overeenkomt met de staat van de broncode en geen handmatige update vereist.

Verschil tussen Marketing Version en Build Number

Marketing Version en Build Number — zijn twee onafhankelijke parameters die verschillende taken oplossen. Marketing Version informeert de gebruiker en Build Number identificeert technisch de build.

Het belangrijkste verschil — uniciteit. Build Number moet uniek zijn voor elke build. Marketing Version kan worden herhaald: meerdere builds van dezelfde versie hebben dezelfde Marketing Version maar verschillende Build Number.

Volgens Google Play Policy (2025), als twee APK's worden geüpload met dezelfde Marketing Version maar verschillende Build Number, accepteert Google Play beide als verschillende builds van dezelfde versie. Voor App Store geldt een vergelijkbare regel.

Onthoud: Build Number — voor machines, Marketing Version — voor mensen. Automatiseer de eerste en plan de tweede zorgvuldig.

Versiebeheerstrategieën

Strategiekeuze voor versiebeheer hangt af van het app-type, het publiek en het releaseproces. Drie hoofdschema's — semantisch, kalender en hybride — dekken de meeste scenario's.

Semantische versie (SemVer) gebruikt het formaat Major.Minor.Patch en bepaalt strikt wanneer welke component moet worden verhoogd. Het is ideaal voor apps met een openbare API en complexe integratie.

Volgens semver.org (2023) wordt versie 2.0.0 van de SemVer-specificatie gebruikt in 89% van open-source mobiele projecten en wordt ondersteund door alle pakketbeheerders.

Kalenderversiebeheer

Kalenderversiebeheer (CalVer) gebruikt de releasedatum als versie — bijvoorbeeld 25.06 voor juni 2025. Deze aanpak is populair in apps met frequente updates.

CalVer geeft geen informatie over de belangrijkheid van wijzigingen, maar toont uitstekend de versheid van de versie. De gebruiker begrijpt onmiddellijk dat versie 25.06 nieuwer is dan 25.03.

Kies kalenderversiebeheer als uw app vaak wordt geüpdatet en gebruikers de actualiteit van gegevens belangrijker vinden dan de omvang van wijzigingen.

Aanbevelingen voor keuze

Voor MVP's en startups is een eenvoudige semantische versie zonder patch (Major.Minor) geschikt. Voor volwassen producten met langdurige ondersteuning — volledige SemVer. Voor apps met continue releases — CalVer.

Gebruik nooit de datum als Build Number — dit kan leiden tot conflicten bij meerdere builds per dag. Build Number moet sequentieel of samengesteld zijn, maar altijd monotoon stijgend.

Fouten bij het kiezen van Marketing Version

Typische fout — het overslaan van een versiecomponent bij overgang naar een nieuwe major-lijn. Bijvoorbeeld na versie 1.9.9 moet de volgende 2.0.0 zijn, niet 1.10.0. Dit schendt de semantiek en verwart gebruikers.

Een ander veelvoorkomend probleem — discrepantie van Marketing Version in code en in de appstore. Controleer altijd dat versionName in build.gradle overeenkomt met de versie in Google Play Console of App Store Connect voordat u een build ter beoordeling indient.

Voorbeelden van Marketing Version instellen

Codevoorbeelden tonen hoe u Marketing Version op beide platforms instelt en het updaten automatiseert.

versionName instellen in Android Gradle

In Android wordt versionName ingesteld in build.gradle. De waarde kan statisch zijn of uit een omgevingsvariabele worden gelezen.

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

// Versie uitlezen uit Git-tag
def getVersionNameFromGit = {
    def tag = "git describe --tags".execute().
        text.trim()
    return tag.startsWith("v") ? tag.substring(1) : tag
}

versionName wordt uit de Git-tag geëxtraheerd, wat overeenstemming tussen de versie in de repository en in de gecompileerde app garandeert.

Marketing Version beheren in Xcode

In iOS wordt Marketing Version ingesteld via Xcode of agvtool. De onderstaande opdracht stelt een nieuwe marketingversie in.

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

# Automatische verhoging
xcrun agvtool next-marketing-version

agvtool werkt automatisch Info.plist bij en synchroniseert de versie tussen alle targets van het Xcode-project.

Fastlane voor beide platforms

Fastlane maakt het mogelijk Marketing Version op beide platforms vanuit één script te beheren, wat ondersteuning van cross-platform projecten vereenvoudigt.

# Marketingversie instellen
increment_version_number(
    version_number: "2.1.0"
)

# Automatische verhoging van minorversie
increment_version_number(
    bump_type: "minor"
)

Fastlane werkt op beide platforms en wordt ondersteund door de meeste CI/CD-diensten.