Version Name: essentie van de parameter en instelling

Wat is Version Name

Version Name — is een semantische tekenreeks die de release van de app voor de gebruiker identificeert. In tegenstelling tot technische build-identificatoren draagt deze parameter een betekenis: op basis hiervan beoordeelt de gebruiker hoeveel de nieuwe update verschilt van de vorige.

Version Name wordt weergegeven in de app-kaart in Google Play en App Store, in het gedeelte „Over de app” op het apparaat, en ook in systeemupdatemeldingen. Ontwikkelaars geven het op in configuratiebestanden van het project voordat ze de releaseversie bouwen.

Volgens Semantic Versioning 2.0 (2023) wordt het formaat Major.Minor.Patch gebruikt in 78% van de mobiele apps. De major-versie verandert bij incompatibele API-wijzigingen, minor — bij het toevoegen van functionaliteit, patch — bij het oplossen van fouten.

Gebruik Version Name voor communicatie met de gebruiker: hij moet onmiddellijk begrijpen hoe groot de aangeboden update is — major, minor of correctief.

Structuur van semantische versie

Semantische versie bestaat uit drie getallen gescheiden door punten: Major.Minor.Patch. Elk van deze componenten is verantwoordelijk voor een bepaald niveau van wijzigingen in de app.

De major-versie (Major) wordt verhoogd bij ingrijpende wijzigingen die de achterwaartse compatibiliteit verbreken. De minor-versie (Minor) voegt nieuwe functionaliteit toe zonder bestaande te verstoren. Patch bevat alleen foutcorrecties.

Bijvoorbeeld, versie 3.2.1 betekent: derde major-versie, tweede minor-update, eerste patch. Dit systeem is begrijpelijk voor zowel ontwikkelaars als gebruikers.

Waar wordt Version Name weergegeven

Version Name is zichtbaar voor de gebruiker op verschillende belangrijke plaatsen. In de app-winkel wordt het weergegeven in de koptekst van de app-kaart en in de updatelijst. Op het apparaat — in systeeminstellingen in het gedeelte „Over de app”.

In Google Play wordt Version Name onder de app-naam weergegeven en beïnvloedt het de beslissing van de gebruiker over updaten. In App Store wordt de versietekenreeks op dezelfde plaats weergegeven bij het bekijken van de app-pagina.

Volgens onderzoek van Apptentive (2024) controleert 67% van de gebruikers de app-versie voor het updaten, en begrijpelijke semantiek verhoogt de conversie naar installatie met 23%.

Version Name op Android

Op Android wordt Version Name ingesteld met de parameter versionName in het bestand build.gradle (op moduleniveau). Deze parameter is een tekenreeks en kan alle tekens bevatten, inclusief punten, koppeltekens en letters.

De parameter wordt gedeclareerd binnen het blok android.defaultConfig samen met de verplichte parameter versionCode. Android legt geen beperkingen op aan het formaat van de tekenreeks, maar Google Play beveelt het gebruik van semantisch formaat aan.

Volgens Android Developers (2025) gebruikt Google Play versionName voor weergave in de winkelinterface, maar analyseert het de inhoud ervan niet programmatisch — alleen versionCode beïnvloedt de updatelogica.

Geef Version Name op in het formaat Major.Minor.Patch en synchroniseer het met de tag in het versiebeheersysteem voor ondubbelzinnige identificatie van de release.

Kenmerken van versionName in Gradle

Gradle maakt het mogelijk versionName statisch in build.gradle of dynamisch via buildscripts in te stellen. Dynamische generatie is nuttig voor automatische nachtelijke builds en CI/CD-pipelines.

In build.gradle kunt u omgevingsvariabelen, opdrachtregelparameters of aanroepen van shellscripts gebruiken om versionName te vormen. Een typische benadering is het lezen van de versie uit het bestand version.properties.

Deze flexibiliteit stelt teams in staat het versiebeheerproces te automatiseren en de menselijke factor bij de releasevoorbereiding te elimineren.

Version Name op iOS

Op iOS wordt Version Name ingesteld met de sleutel CFBundleShortVersionString in het bestand Info.plist. Dit is een verplichte parameter voor publicatie in App Store en is strikt getypt als tekenreeks.

In tegenstelling tot Android controleert App Store Connect het formaat van Version Name en eist het conformiteit met het patroon van door punten gescheiden getallen. De maximale tekenreekslengte is 18 tekens en elke versiecomponent mag niet groter zijn dan 255.

Volgens Apple Developer Documentation (2025) wordt CFBundleShortVersionString door App Store gebruikt om de versie weer te geven in de winkelinterface en in systeemdialogen op het apparaat van de gebruiker.

Zorg er bij het uploaden van een build naar App Store Connect voor dat Version Name overeenkomt met de versie die in marketingmateriaal wordt vermeld — dit vereenvoudigt de communicatie met gebruikers.

Integratie met Xcode

Xcode biedt een grafische interface voor het wijzigen van Version Name in de target-instellingen. Het veld „Marketing Version” bevindt zich op het tabblad General in het gedeelte Identity. Wijzigingen worden automatisch opgeslagen in Info.plist.

Voor automatisering kunt u buildscripts gebruiken in Xcode Build Phases of het hulpprogramma agvtool (Apple Generic Version Tool). agvtool maakt versiebeheer vanaf de opdrachtregel en integratie met CI/CD mogelijk.

Een dergelijke aanpak is bijzonder handig bij gebruik van fastlane of Jenkins voor automatisch bouwen en leveren van apps.

Verschillen tussen Version Name en Build Number

Version Name en Build Number vervullen verschillende taken in het ontwikkelproces. Version Name is een gebruikerstekenreeks en Build Number is een interne numerieke identificator die elke build uniek identificeert.

Build Number (versionCode in Android, CFBundleVersion in iOS) moet worden verhoogd bij elke nieuwe build en wordt door app-winkels gebruikt om te bepalen welke versie nieuwer is. Version Name kan ongewijzigd blijven voor meerdere builds van dezelfde versie.

Volgens Google Play Policy (2025) worden twee apps met dezelfde versionCode als dezelfde versie beschouwd — versionCode moet uniek zijn voor elke APK. Version Name neemt niet deel aan deze controle.

Verhoog altijd Build Number bij elke build en wijzig Version Name alleen bij wijziging van functionaliteit — dit voorkomt conflicten bij publicatie.

Hoe Version Name te kiezen

Keuze van Version Name hangt af van de versiebeheerstrategie van het team. De meest voorkomende benadering is semantisch versiebeheer (SemVer), maar er zijn ook alternatieve schema’s, zoals kalenderversiebeheer of versiebeheer op basis van releasedatum.

Semantic Versioning 2.0 beveelt het formaat Major.Minor.Patch aan met optionele pre-release suffixen. Voor mobiele apps is ook het schema Major.Minor populair, waarbij patch wordt weggelaten voor eenvoudigere perceptie.

Kalenderversiebeheer (CalVer) gebruikt de releasedatum als versienummer — bijvoorbeeld 25.06 (jaar en maand). Deze benadering is handig voor apps met frequente releases, waar semantiek niet belangrijk is.

Aanbevelingen voor het kiezen van een schema

Semantisch versiebeheer is geschikt voor apps met een publieke API, waar achterwaartse compatibiliteit belangrijk is. Gebruikers en integratoren begrijpen welke wijzigingen ze bij een update kunnen verwachten.

Kalenderversiebeheer wordt gekozen voor apps waar de gebruiker de versheid van de release belangrijk vindt, niet de omvang van wijzigingen. Bijvoorbeeld nieuwsaggregators of weerapps.

Hybride schema combineert beide benaderingen: Major.Minor.RC, waarbij RC het buildnummer is voor een specifieke releasekandidaat. Een dergelijk schema is handig bij actief bèta-testen.

Voorbeelden van Version Name-configuratie

Codevoorbeelden hieronder tonen hoe u Version Name instelt op Android en iOS. Voor Android wordt Gradle gebruikt, voor iOS — Xcode Build Settings met agvtool.

Configuratie van versionName in Android

In Android wordt de versie ingesteld in het bestand app/build.gradle binnen het blok defaultConfig. De parameter versionName accepteert een tekenreekswaarde.

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

versionName kan ook worden gelezen uit een extern bestand of dynamisch worden gegenereerd met Gradle Script.

Dynamische generatie van versionName

Dynamische versie wordt gevormd uit omgevingsvariabelen van het CI/CD-systeem. Dit garandeert dat elke build het juiste versienummer krijgt.

def getVersionName = {
    return System.getenv("VERSION_NAME") ?:
            "2.1.0"
}

android {
    defaultConfig {
        versionName getVersionName()
    }
}

Een dergelijke aanpak automatiseert versiebeheer en elimineert het risico van mismatch tussen build en tag in de repository.

Configuratie van CFBundleShortVersionString in iOS

In iOS kan de versie worden ingesteld via Xcode of via de opdrachtregel met agvtool.

# Instellen van marketingversie
xcrun agvtool new-marketing-version 2.1.0

# Uitlezen van huidige versie
xcrun agvtool what-marketing-version

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