Jedes Mal, wenn du ein Update shippst, bekommst du 4.000 Zeichen, um Apple zu sagen, was sich geändert hat. Die meisten indie Entwickler nutzen weniger als 40.

“Bug fixes and performance improvements” sind keine Versionshinweise. Es ist verschwendete Fläche, und unter Apples 2026-Guidelines könnte es sogar gegen die Position deiner App im Store arbeiten.

Was Versionshinweise tatsächlich leisten

Versionshinweise im App Store bedienen drei separate Zielgruppen gleichzeitig:

  1. Bestehende User, die entscheiden, ob sie updaten
  2. Potenzielle User, die den Versionsverlauf-Abschnitt deiner Product Page lesen
  3. Apples Indexing-Systeme, die evaluieren, ob das Update bedeutsame, aktive Entwicklung repräsentiert

Die meisten indie Entwickler schreiben nur für die erste Zielgruppe oder lassen Versionshinweise ganz weg, weil sie nach dem Shippen eines Builds unter Zeitdruck stehen. Das ist ein Fehler.

Apples App Store-Suchalgorithmus behandelt die Update-History deiner App als Signal. Nicht die Versionsnummer, nicht die Binary-Größe. Den Inhalt deiner Versionshinweise. Eine App mit beschreibenden, spezifischen Versionshinweisen über eine konsistente Update-History hinweg signalisiert aktive Wartung. Eine App mit “Bug fixes.” in jedem Update-Slot signalisiert das Gegenteil.

Mit dem WWDC26-Guidelines-Update hat Apple sein erklärtes Recht erweitert, Apps zu entfernen, die “not updated or improved” sind. Dein Versionshinweise-Feld ist ein direktes Fenster in die Frage, ob deine App bedeutsam aktualisiert wurde. Wenn deine letzten fünf Einträge alle “minor improvements” sagen, liest sich deine Update-History als dormant — unabhängig davon, was tatsächlich im Binary geshippt wurde.

Wie Apple Versionshinweise indexiert

Apple indexiert Text über deine gesamte Product Page hinweg, um zu bestimmen, für welche Suchanfragen deine App infrage kommt. Die am höchsten gewichteten Felder sind dein Title, Subtitle und Keyword-Feld. Darunter verarbeitet Apple deine Description, Promotional Text und Versionshinweise.

Versionshinweise werden bei jedem Update neu indexiert. Das heißt, jedes Mal, wenn du shippst, hast du ein frisches Fenster, um neue Begriffe einzuführen, die reflektieren, was deine App jetzt tut. Wenn du ein neues Feature geshippt hast, ist der Versionshinweise-Eintrag der schnellste Weg, dieses Feature indexiert zu bekommen, bevor deine nächste vollständige Metadata-Submission ansteht.

Das ist relevant für Features, die beim Launch noch nicht existierten. Wenn du seit dem Schreiben deiner ursprünglichen Metadata Dark-Mode-Support, ein Widget, eine Share Extension oder einen neuen Workflow hinzugefügt hast, erwähnt dein Keyword-Feld diese Features wahrscheinlich gar nicht. Ein Versionshinweise-Eintrag, der das neue Feature beschreibt, bringt diesen Begriff sofort in Apples Index.

Das ist kein Loophole. Es ist die Nutzung des Tools genau so, wie Apple es designt hat. Das Feld existiert, damit Entwickler Änderungen kommunizieren können. Apple indexiert Änderungen, weil sie für User relevant sind, die nach Apps mit spezifischer Funktionalität suchen.

Der spezifische Fehler, den die meisten Apps machen

Öffne App Store Connect und schau dir deine letzten zehn Versionshinweise-Einträge an.

Wenn sie so aussehen:

  • “Bug Fixes”
  • “Performance-Verbesserungen”
  • “Kleinere Stabilitäts-Updates”
  • “Wir haben hart daran gearbeitet, deine Experience zu verbessern”

Dann versorgst du nicht nur deine User schlecht. Du schreibst Content, der für Apples Indexing-Systeme unsichtbar ist.

“Bug Fixes” enthält kein Keyword-Signal. “Performance-Verbesserungen” ist kein Suchbegriff, den irgendjemand eintippt. “Hart daran gearbeitet, deine Experience zu verbessern” ist eine Filler-Phrase, die von jedem Ranking-System rausgefiltert wird, das natürliche Sprache verarbeitet.

Vergleich das mit:

Focus Filter-Integration hinzugefügt, sodass sich deine App-Liste an deinen aktuellen Focus-Modus anpasst. Keyword-Vorschläge verbessert, um das monatliche Suchvolumen für jeden Begriff anzuzeigen. Crash auf iPad behoben, der beim Öffnen der Competitor-Analyse-View mit mehr als 50 getrackten Apps auftrat.

Diese Version benennt ein spezifisches Feature (Focus Filter-Integration), nennt Category-Begriffe, die Apple indexieren kann (Keyword-Vorschläge, Suchvolumen), beschreibt einen echten Fix mit Plattform-Kontext (iPad-Crash) und enthält natürliche Sprache, die dem entspricht, wie Entwickler nach Funktionalität suchen.

Einer dieser Einträge arbeitet für dich. Der andere nicht.

Eine Formel, die funktioniert

Schreib Versionshinweise in drei Teilen:

Führ mit dem Feature, konkret benannt. “Geplante Keyword-Reports hinzugefügt” ist indexierbar. “Verbesserungen am Reports-Bereich” ist es nicht. Wenn du einen neuen Screen geshippt hast, nenn den Screen. Wenn du eine Integration hinzugefügt hast, nenn das Integrations-Ziel. Spezifität ist es, was indexiert wird, und Spezifität ist auch das, wonach User scannen, wenn sie entscheiden, ob sie updaten.

Nenn den Use Case, nicht den Mechanismus. “Verfolge Competitor-Keyword-Änderungen über 50 Storefronts mit täglichen E-Mail-Digests” ist search-adjacent. “Backend-Optimierung für Competitor-Tracking” ist es nicht. Schreib aus der Perspektive des Users, nicht der des Engineers.

Beschreib Fixes mit Kontext. Bug Fixes gehören in Versionshinweise, aber sie sollten enthalten, was kaputt war, auf welchem Gerät oder welcher Konfiguration, und wie das erwartete Verhalten jetzt ist. “Crash auf iPhone SE behoben, der beim Submitten von Metadata mit japanischen Zeichen auftrat” ist nützlich. “Crash behoben” ist es nicht.

Unter dieser Formel könnte ein Versionshinweise-Eintrag für ein substanzielles Update so aussehen:

CSV-Export für Keyword-Rank-History hinzugefügt. Du kannst jetzt 90 Tage Rank-Daten pro Keyword, pro Storefront, direkt aus der Tracking-View exportieren. Der Export wird über das Icon oben rechts im Keywords-Tab ausgelöst.

Verbesserte ASO-Score-Berechnung, um Promotional-Text-Aktualität und Review-Response-Rate als separate Signale zu gewichten.

Falsche Zeichenanzahl im Keyword-Feld-Editor bei Mixed-Script-Locales (Japanisch, Koreanisch, Chinesisch) behoben.

Dieser Eintrag ist rund 400 Zeichen lang, deutlich innerhalb des 4.000-Zeichen-Limits, und enthält indexierbare Begriffe über die Metadata- und Localization-Kategorien hinweg. Er beschreibt echte Änderungen, die User verifizieren können, und signalisiert Apple, dass das Update substanziell war.

Wie Versionshinweise mit dem 2026-Purge-Risiko zusammenhängen

Apples Guideline-Sprache — “not updated, improved, or does not attract customers” — gilt für bereits veröffentlichte Apps. Deine Versionshinweise sind Teil der Evidenz, die Apple bewertet, wenn es Update-Aktualität einschätzt.

Eine App mit beschreibenden, feature-spezifischen Versionshinweisen über die letzten mehreren Updates hinweg liest sich für Apples Systeme anders als eine App, deren gesamte History “Bug fixes and performance improvements” ist. Erstere demonstriert konsistente, aktive Entwicklung. Letztere liefert in keine Richtung ein Signal, was fast so schlecht ist wie gar keine Updates.

Wenn du das Metadata-Audit aus dem vorherigen Post dieser Serie durchgeführt hast: Update-Aktualität war einer der sechs Checks. Starke Versionshinweise sind der operative Mechanismus hinter diesem Check. Du kannst kein “active development” beanspruchen mit einem Binary-Update, wenn die Versionshinweise nichts darüber sagen, was sich geändert hat.

Wie oft du deine Versionshinweise-Strategie überprüfen solltest

Versionshinweise sind live, bis zu deinem nächsten Update. Überprüf sie als Teil deiner Standard-Pre-Submission-Checkliste:

  • Vor dem Shippen eines bedeutsamen Features: entwirf die Versionshinweise parallel zum Feature, nicht danach
  • Bei Maintenance-Releases: beschreib, was sich tatsächlich geändert hat, auch wenn die Änderungen klein sind
  • Nach einem großen Plattform-Update (neue iOS-Version, neuer Device-Support): erwähn Kompatibilität explizit in den Hinweisen

Zur Frequenz: Apple veröffentlicht keinen Schwellenwert dafür, wie oft Updates geshippt werden müssen, aber das Muster, das in Developer-Account-Warnungen auftaucht, legt nahe, dass sechs Monate ohne substanzielles Update im Risiko-Fenster liegen. Konsistente Releases mit beschreibenden Hinweisen über ein rollierendes 90-Tage-Fenster liefern stärkere Evidenz für Wartung als ein einzelnes großes Update alle acht Monate.

Was du vor deiner nächsten Submission tun kannst

Du kannst vergangene Versionshinweise nicht rückwirkend umschreiben. Aber jedes Update von jetzt an ist ein Clean Slate.

Vor deiner nächsten App Store-Submission:

  1. Öffne einen Entwurf und liste jede User-sichtbare Änderung im Build auf
  2. Schreib für jede Änderung einen Satz, der das Feature und den Use Case benennt, den es adressiert
  3. Füg für jeden Bug Fix die betroffene Plattform oder den Kontext hinzu
  4. Kombinier alles im Versionshinweise-Feld (300 bis 500 Zeichen reichen meist für einen substanziellen Eintrag; das 4.000-Zeichen-Limit gibt dir Raum, tiefer zu gehen, wenn das Update es rechtfertigt)

Das dauert fünfzehn Minuten. Es ist die günstigste indexierbare Metadata, die du je produzieren wirst, und sie stackt mit jeder anderen Metadata-Investition, die du machst. Mach es, bevor du auf Submit drückst.

Martesos AI Metadata Optimizer hilft dabei, keyword-bewussten Content über dein gesamtes Listing hinweg zu entwerfen. Wenn du deine aktuelle Metadata noch nicht auditiert hast, zeigt dir marteso.com/aso-score-checker genau, wo dein Listing underperformt — noch bevor dein nächstes Update live geht.