Versionsnummern lesen: was die Release-Historie über eine App verrät
Vor jedem Erstgespräch schauen wir uns die Store-Seite der App an. Nicht die Screenshots, nicht die Beschreibung — die Versionshistorie. Oft reicht eine Zeile: „Version 2.4.1 · Aktualisiert vor 14 Monaten.” Danach muss man wenig fragen. Nicht weil eine alte Version ein Urteil wäre, sondern weil unter dieser Zeile eine Liste steht, die selten lügt: welche Nummern es gab, in welchen Abständen sie kamen, und was jeweils dabeistand.
Die Kurzfassung: Die Versionshistorie im Store ist die einzige öffentlich einsehbare Pflegeakte deiner App. Aussagekräftig ist dabei weder das Nummernschema noch die Lückenlosigkeit — Lücken entstehen in jedem gesunden Release-Prozess. Aussagekräftig sind zwei Abstände: der zwischen den Releases und der zwischen dem letzten Release und heute.
Dieser Artikel erklärt, was in einer Versionsnummer wirklich steckt, welche Lücken harmlos sind und welche nicht, und wie du die Historie einer App in zehn Minuten liest — mit demselben Blick, mit dem wir sie lesen.
Was in einer Versionsnummer steckt — und was nicht
Die verbreitete Lesart ist schnell erzählt: Die erste Zahl steht für einen Bruch oder eine neue Generation, die zweite für neue Funktionen, die dritte für Korrekturen. Eine sinnvolle Konvention — aber eine Konvention, keine Vorschrift.
Denn der Store leitet aus der Nummer fast nichts ab. Er sortiert damit, welche Version neuer ist als die vorige. Kein Ranking, keine besondere Benachrichtigung, keine zusätzliche Sichtbarkeit. Alles, was eine Nummer bewirkt, bewirkt sie über die Erwartung, die sie bei Menschen erzeugt.
Wie locker das genommen wird, lässt sich in zwei Minuten nachsehen. Apples Dokumentation verlangt für die nutzersichtbare Version ausdrücklich „drei durch Punkte getrennte Ganzzahlen”. Im deutschen App Store stand die Post & DHL App im September 2026 auf 10.0, die ZDF-App auf 6.9, POSTIDENT auf 33.3 — alle zweiteilig, alle unbeanstandet. Die dokumentierte Formatregel wird nicht durchgesetzt.
Zwei Nummern, die dauernd verwechselt werden
Neben der Versionsnummer trägt jedes Release eine zweite Zahl: die Build-Nummer. Die Versionsnummer sehen die Nutzer. Mit der Build-Nummer hält der Store zwei Uploads derselben Version auseinander — sie läuft bei jedem Bauvorgang weiter und wird nie zurückgesetzt.
Deshalb ist sie fast immer deutlich höher als die Zahl der veröffentlichten Versionen. Bei cyclotest mySense lautet der jüngste Versionsstempel 4.3.2+377, während im Store Version 4.3.2 läuft: Hinter 226 ausgelieferten Store-Releases stehen dort 377 Bauvorgänge.
Die Plattformen behandeln das gegensätzlich, und daraus entstehen die meisten Missverständnisse. Auf iOS ist die sichtbare Nummer selbst die geordnete: Sie muss bei jedem Upload höher sein als die letzte freigegebene. Auf Android ist die sichtbare Nummer technisch ein beliebiger Text ohne erzwungenes Format, und die Ordnung trägt eine zweite, unsichtbare Zahl. Dieselbe Zeile bedeutet also nicht dasselbe.
Warum Lücken der Normalfall sind
Apple prüft beim Upload genau eine Regel: Die neue Version muss höher sein als die letzte freigegebene. Nicht „um eins höher”. Von 1.2.0 auf 1.4.0 zu springen ist völlig zulässig. Genau deshalb entstehen Lücken überhaupt — und zwar aus fünf ganz alltäglichen Gründen.
Ein Build wurde zurückgezogen. Nach dem Hochladen fällt noch ein Fehler auf. Die Nummer ist verbraucht, der nächste Versuch bekommt die nächste — jemand hat also hingeschaut, bevor es die Nutzer traf.
Das Review hat abgelehnt. Die Version existierte, wurde eingereicht und kam nie an.
iOS und Android laufen getrennt. Zwei Stores, zwei Nummernkreise, keinerlei Pflicht, sie gleichzuhalten. Die TK-App stand am 9. September 2026 auf iOS bei 10.4.1 und auf Android bei 10.3.1 — die iOS-Historie kennt kein 10.3.1 überhaupt.
Es war ein Testbuild. Eine Verteilung an Tester verbraucht eine Nummer, ohne je öffentlich zu erscheinen.
Es wurde gestaffelt ausgerollt. Wird ein Rollout gestoppt, bleibt die Nummer als halb ausgelieferter Stand zurück.
Vier dieser fünf Ursachen sind Zeichen eines Prozesses, der funktioniert. Eine lückenlose Nummernfolge ist deshalb kein Qualitätsmerkmal — sie ist meistens nur ein Hinweis darauf, dass selten ausgeliefert wird.
Vier echte Verläufe, nachlesbar
Der iOS-Versionsverlauf ist öffentlich — man kann das also nachprüfen. Wir haben es im September 2026 für vier große deutsche Apps getan.
Die TK-App zeigt den auffälligsten Fall: Auf 9.7.2 vom 4. Juni folgt 10.1.0 vom 30. Juni — die gesamte 10.0er-Linie fehlt. Der Verlauf ist dort lückenlos datiert, ein zwischenzeitliches 10.0.0 müsste also auftauchen. Belegt ist damit genau eine Aussage: Es wurde nie eine 10.0 öffentlich ausgeliefert. Ob eine gebaut und verworfen wurde, wissen nur die Beteiligten.
Bei der Sparkasse-App fehlen im sichtbaren Fenster fünf Nummern: 7.3.4, 8.0.1, 8.1.3, 8.2.0 und 8.2.1 — die 8.2-Linie beginnt öffentlich erst bei 8.2.2. Im selben Verlauf steht die längste Pause aller vier Apps mit 56 Tagen, daneben drei Tage Abstand zwischen 8.2.2, 8.2.3 und 8.2.4: der klassische Hotfix-Burst.
Der DB Navigator nummeriert nach Jahr und Release, 26.14.0 ist das vierzehnte Release des Jahres 2026. Elf Nummern fehlen, darunter vier aufeinanderfolgende Patch-Stände. Und trotzdem ist dieser Verlauf der disziplinierteste von allen: Zählt man je Release-Nummer nur die erste öffentliche Version, liegt der Median-Abstand bei exakt 14 Tagen — 9 von 15 Abständen sind auf den Tag genau zwei Wochen.
Kleinanzeigen ist die Gegenprobe. Dort steckt der Kalender in der Version: 2026.37.1 ist die Kalenderwoche 37 des Jahres 2026. Die Wochen 24 bis 37 sind vollständig, ohne eine einzige Lücke, bei einem Median-Abstand von vier Tagen.
Zwei Extreme derselben Mechanik: Kleinanzeigen macht die Nummer zum Kalender und liefert jede Woche. Sparkasse und DB Navigator numerieren fortlaufend und veröffentlichen ausgewählt — ihre Nummer ist ein Protokoll mit Löchern. Keiner der Wege ist falsch, und keine dieser Lücken ist ein Befund. (Alle Angaben Stand 09/2026 — Versionsverläufe ändern sich mit jedem Release.)
Die eine Lücke, die wirklich etwas bedeutet
Der einzige Befund, der ohne weitere Information trägt, ist der zeitliche. Nicht welche Nummer fehlt, sondern wie lange nichts kam.
Ab etwa einem Jahr ohne Release läuft die Kette an, die wir in App-Wartung: Wenn Apple und Google die Frist setzen beschrieben haben: erst lassen sich keine Updates mehr einreichen, dann verschwindet die App aus der Suche, am Ende ganz aus dem Store. Apple hat das sogar ausbuchstabiert — Apps ohne Update seit drei Jahren, die zusätzlich eine Mindestzahl an Downloads verfehlen, werden entfernt; 90 Tage vorher kommt eine E-Mail.
Zwei weitere Muster sind ähnlich deutlich. Ein einzelnes Release direkt vor einer Store-Frist und sonst zwei Jahre Stille ist keine Pflege, sondern Fristwahrung. Und wenn nur noch eine Plattform Updates bekommt, ist das selten eine Entscheidung — meistens fehlt ein Zugang, ein Zertifikat oder eine Person. Zeigt die Historie, dass es kein kleines Update mehr wird, stellt sich die Frage modernisieren oder neu bauen.
Was du selbst in zehn Minuten prüfen kannst
Vier Fragen an die eigene Store-Seite, alle ohne technisches Wissen beantwortbar:
- Wann war das letzte Update? Steht öffentlich auf der Store-Seite.
- Wie groß sind die Abstände zwischen den letzten sechs Releases?
- Steht unter allen sechs derselbe Änderungstext?
- Haben iOS und Android denselben Stand?
Diese vier Antworten stehen öffentlich — auch bei der App deines Wettbewerbers und bei jeder App, die dir jemand als Referenz zeigt. Ein Detail lohnt zu wissen: Der öffentliche iOS-Verlauf endet nach 25 Einträgen. Wer schnell releast, hat deshalb das kürzere öffentliche Gedächtnis — bei der TK-App reichen 25 Einträge gut ein Jahr zurück, bei Kleinanzeigen nur drei Monate.
Wenn im dritten Punkt zwölfmal „Fehlerbehebungen und Verbesserungen” steht, lohnt ein Blick darauf, wie man Release Notes schreibt, die etwas sagen. Und wer die Release-Daten neben den Bewertungsverlauf legt, hat die schnellste Ursachenzuordnung, die ohne Codezugang möglich ist — dazu steht mehr in Store-Bewertungen als Frühwarnsystem.
Ein Schema, mit dem man leben kann
Es gibt kein richtiges Nummernschema. Es gibt drei Eigenschaften, die jedes brauchbare hat: Es steigt monoton, es ist von außen erklärbar, und es liegt zusammen mit dem Code im Repository statt in jemandes Kopf.
Ob dabei Nummern fehlen, ist gleichgültig. Ob nachvollziehbar bleibt, welche Nummer wann im Store stand, ist es nicht — das ist der Unterschied zwischen einer Historie, die man liest, und einer, die man rekonstruieren muss. Wer sich das vor dem ersten Release überlegt, muss es später nicht nachholen; dann gehört es auf die Checkliste vor dem Launch. Welches Schema konkret passt und wie oft du ausliefern solltest, beantwortet der Ratgeber zur Release-Kadenz auf app-care.de.
Der ehrliche Teil
Aus der Versionshistorie allein lässt sich keine App beurteilen. Eine App mit monatlichen Releases kann trotzdem abstürzen. Und eine App, die seit acht Monaten unverändert im Store steht, kann genau richtig sein — wenn sie fachlich fertig ist, keine Bibliothek mit offener Sicherheitswarnung enthält und die nächste Store-Frist bei jemandem im Kalender steht.
Wer aus einer alten Versionsnummer ein Urteil macht, verkauft etwas. Was die Historie liefert, ist eine Frage, keine Antwort. Und die Frage lautet nicht „warum so alt?”, sondern: weiß jemand, warum?
Passend dazu: Wir übernehmen Betrieb und Wartung bestehender Apps — auch für Apps, die wir nicht gebaut haben. Wie das abläuft, steht auf der Seite zur App-Pflege.