Mobile-App-Sachverständigung
Bei mobilen Anwendungen sind sichtbare Versionsnummer, interne Build-Kennung, hochgeladener Store-Build und tatsächlich installierter Stand nicht dieselbe Information. Für zeitbezogene Untersuchungen müssen diese Ebenen getrennt rekonstruiert werden.
Kurzantwort
Android unterscheidet versionCode und versionName; Apple unterscheidet unter anderem Version Number und Build String.
Ein in einen Store hochgeladener Build ist nicht automatisch der veröffentlichte oder auf einem konkreten Gerät installierte Build.
Von der sichtbaren Versionsnummer zum belegten Installationsstand
1. Sichtbare Version und interne Build-Kennung trennen
Mobile Plattformen verwenden unterschiedliche Metadaten für Release- und Buildidentifikation.
Android versionName ist nicht versionCode
Die benutzersichtbare Versionsbezeichnung und die intern zur Versionsordnung verwendete Kennung erfüllen unterschiedliche Funktionen.
Apple Version Number ist nicht Build String
Auch auf Apple-Plattformen müssen benutzersichtbare Version und einzelne Build-Kennung getrennt dokumentiert werden.
2. Store-Upload und veröffentlichten Stand unterscheiden
Ein Build kann technisch hochgeladen sein, ohne bereits die öffentlich verfügbare Store-Version zu sein.
Upload belegt zunächst Bereitstellung an die Store-Infrastruktur
Daraus folgt nicht automatisch, dass dieser Build zu einem bestimmten Zeitpunkt öffentlich verteilt wurde.
Store-Anzeige ist ein eigener zeitbezogener Befund
Für historische Aussagen sind Zeitpunkt und konkret sichtbarer Release-Stand zu dokumentieren.
3. Tatsächlich installierten Build gesondert sichern
Der Gerätebestand kann vom aktuell im Store sichtbaren Stand abweichen.
Installierte Version kann älter als Store-Version sein
Nutzergeräte müssen einen verfügbaren Store-Stand nicht sofort übernehmen.
Gleiche sichtbare Version kann unterschiedliche Builds verdecken
Deshalb ist bei Streit über konkrete Fehler der interne Build besonders relevant.
4. Release- und Installationszeitachse rekonstruieren
Versionen erhalten erst durch ihren Zeitbezug sachverständige Aussagekraft.
Heutiger Store-Stand beweist keinen früheren Gerätestand
Historische Aussagen benötigen zeitnahe Geräte-, Release- oder Deploymentnachweise.
App-Update und Fehlerzeitpunkt sind getrennte Befunde
Zeitliche Nähe kann eine Untersuchungshypothese begründen, ist aber kein automatischer Ursachenbeweis.
| Ebene | Beispiel | Nicht automatisch bewiesen |
|---|---|---|
| Sichtbare Version | versionName / Version Number | konkreter Build |
| Build | versionCode / Build String | öffentlicher Store-Release |
| Store-Upload | hochgeladener Build | Veröffentlichung |
| Store-Stand | öffentlich angebotene Version | Geräteinstallation |
| Gerätestand | installierte App | Stand anderer Geräte |
5. Metadaten mit Artefakt- und Gerätebefunden verbinden
Mehrere Nachweisquellen können denselben oder widersprüchliche Stände zeigen.
Versionsstring allein ist kein vollständiger Buildnachweis
Für kritische Zuordnungen sollten verfügbare Build- und Installationsinformationen gemeinsam ausgewertet werden.
Warum ein hochgeladener Build noch keinen produktiv installierten Stand beweist
Upload, Veröffentlichung und Installation sind verschiedene technische Ereignisse.
Eine belastbare historische Aussage benennt deshalb ausdrücklich, welche dieser Ebenen belegt ist.
6. Rekonstruktion auf belegte Release-Ebenen begrenzen
Fehlende historische Store- oder Geräteinformationen reduzieren die Aussagefähigkeit.
Nicht belegte Zwischenstände dürfen nicht angenommen werden
Eine lückenhafte Releasekette muss als Aussagegrenze dokumentiert werden.
Ist der App-Release-Stand vollständig rekonstruiert?
- Ist die App eindeutig identifiziert?
- Sind sichtbare Version und Build-Kennung getrennt?
- Sind versionCode/versionName beziehungsweise Version Number/Build String dokumentiert?
- Ist der Store-Upload-Zeitpunkt bekannt?
- Ist der veröffentlichte Store-Stand bekannt?
- Ist der installierte Gerätestand gesichert?
- Sind Update- und Fehlerzeitpunkt getrennt?
- Sind Lücken der historischen Releasekette ausgewiesen?
Konstruiertes Beispiel
Im Store wird Version 4.2 angezeigt, während das betroffene Gerät noch einen älteren Build derselben sichtbaren Version trägt. Für die Fehlerrekonstruktion ist deshalb der Geräte-Build entscheidend und nicht allein der heutige Store-Eintrag.
Das Beispiel erläutert ausschließlich die Prüfmethode. Es beschreibt kein reales Mandat, keine konkrete App und keine tatsächlich festgestellte Fehlerursache.
Quellen und fachliche Grundlage
- Technische Maintainerquelle Android Developers – Version your app . Dokumentation von versionCode und versionName sowie ihrer unterschiedlichen technischen Rollen. Geprüft am 20.10.2026.
- Technische Maintainerquelle Apple Developer – Version number . Dokumentation der benutzersichtbaren Versionsnummer CFBundleShortVersionString. Geprüft am 20.10.2026.
- Technische Maintainerquelle Apple Developer – Build string . Dokumentation von CFBundleVersion als technische Build-Kennung. Geprüft am 20.10.2026.
- Technische Maintainerquelle Apple Developer – Upload builds . Dokumentation des Uploads und der Zuordnung von Builds in App Store Connect. Geprüft am 20.10.2026.
- Technische Maintainerquelle Android Developers – Application Fundamentals . Grundlagen zu Android-Anwendungskomponenten, Prozess- und Anwendungskontext. Geprüft am 20.10.2026.
- Eigene fachliche Einordnung Die technische Zusammenführung von App-Build, Geräte- und OS-Zustand, Lifecycle, lokalen Daten, Netzwerkbefunden, Gegenhypothesen und Aussagegrenzen richtet sich nach der konkreten Untersuchungsfrage. Eigene fachliche Interpretation ersetzt keinen externen Primärnachweis.
Weiterführende Beiträge
Repository, Commit, Branch und Build
Mobile Apps technisch untersuchen
Wenn App-Build, Geräteabhängigkeit, Berechtigungen, lokale Daten, Backend-Synchronisation oder mobile Hintergrund- und Notification-Abläufe nachvollziehbar untersucht werden sollen, können Fragestellung, Prüfstand und technische Evidenz zunächst unabhängig eingegrenzt werden.
Software-Gutachten ansehen