Release Notes für Mobile Apps: Was das Limit streicht

Alles in diesem Hub übers Schreiben von Release Notes geht von einer Seite aus, die man selbst kontrolliert: beliebige Länge, funktionierende Links, Formatierung, die gerendert wird. Die Release Notes einer mobilen App leben in der Box eines anderen. Apple gibt ungefähr 4.000 Zeichen, zeigt aber nur die ersten paar Zeilen, bevor “Mehr” getippt wird; Google gibt ähnlich viel Platz mit demselben Vorschau-Problem, und keine der beiden Plattformen rendert einen klickbaren Link im Text. Die Regeln aus wie man Release Notes schreibt, die tatsächlich gelesen werden gelten immer noch: sagen, was sich geändert hat und was die Leserin tun muss, aber der Platz dafür ist ein Bruchteil dessen, was eine Changelog-Seite erlaubt, und die Kürzungen müssen bewusst gemacht werden statt versehentlich zu passieren.

Was passt eigentlich in die sichtbare Vorschau?

Die ersten ein bis zwei Zeilen, ungefähr 80 bis 170 Zeichen je nach Gerät und Schriftgröße, bevor eine Leserin tippen muss, um zu erweitern. Das ist das gesamte Budget für den Teil der Release Note, der entscheidet, ob überhaupt jemand den Rest liest, und es bedeutet, dass der wichtigste Satz zuerst kommen muss, nicht die Versionsnummer, keine Begrüßung, keine Kategorie-Überschrift. Eine Release Note, die mit “Neu in dieser Version:” beginnt, hat bereits ein Drittel des sichtbaren Platzes für vier Wörter verbraucht, die der Leserin nichts sagen.

Funktioniert die Regel “was kann man jetzt, was schuldet man” auf dieser Länge noch?

Ja, und sie wird strenger, nicht anders. Ein Satz pro Eintrag, Verb zuerst, keine Einleitung: “Daten als CSV aus den Einstellungen exportieren.” schlägt “Wir haben die Möglichkeit hinzugefügt, dass Nutzerinnen ihre Daten jetzt im CSV-Format exportieren können” mit einem Drittel der Wörter für dieselbe Aussage. Bei Changelog-Seiten-Länge kostet ein etwas geschwätziger Satz eine Leserin eine halbe Sekunde. Bei der Länge mobiler Release Notes kann dieselbe Geschwätzigkeit den Satz komplett aus der sichtbaren Vorschau schieben, sodass die Leserin das Verb nie sieht, das ihr gesagt hätte, was sich geändert hat.

Schlecht, verschwendet die Vorschau auf Rahmen:
"Wir freuen uns, ein neues Update voller Verbesserungen
zu bringen! Lies weiter für Details."

Gut, der ganze Wert in der ersten Zeile:
"Daten als CSV exportieren. Dunkelmodus respektiert
jetzt die Systemeinstellung. Absturz beim Öffnen
geteilter Links behoben."

Was muss gestrichen werden, das ein Web-Changelog-Eintrag normalerweise behält?

Links, zuerst, weil keiner der beiden Stores sie klickbar rendert, sodass eine URL im Text totes Gewicht ist, das eine Leserin abtippen müsste. Wenn der Eintrag ein Ziel braucht, sag stattdessen, was in der App zu tippen ist: “Neue Filter unter Einstellungen > Suche” funktioniert; “Mehr lesen unter example.com/blog/filter” funktioniert auf dieser Oberfläche nicht. Zweitens alles Bedingte oder Zielgruppenspezifische: Ein Web-Changelog kann sagen “wenn du die API nutzt, betrifft dich das”, aber ein Store-Eintrag erreicht jeden installierten Nutzer gleichzeitig, sodass eine bedingte Zeile für die 95 %, auf die sie nicht zutrifft, wie Rauschen wirkt. Setze das bedingte Detail stattdessen in eine In-App-Nachricht, ausgelöst für die Konten, die es tatsächlich betrifft.

Sollte jedes Release eigene Notes bekommen, oder ist “Fehlerbehebungen und Leistungsverbesserungen” in Ordnung?

Nutze das wieder für Releases, die genau das sind, aber prüfe, wie oft das wirklich stimmt. Wie man Release Notes schreibt behandelt bereits, warum diese Phrase eine Note verrät, die von innen statt für die Leserin geschrieben wurde; auf mobilen Plattformen richtet sie doppelten Schaden an, weil Store-Release-Notes einer der wenigen Orte sind, an denen manche Nutzerinnen zwischen Updates überhaupt etwas sehen, und eine lange Serie von “Fehlerbehebungen und Leistungsverbesserungen” liest sich, als würde sich die App nicht ändern, was für diese Zeitspanne einen schlechteren Eindruck macht als gar keine Notes.

Beeinflussen Release Notes überhaupt, ob Leute die App aktualisieren?

Indirekt, über Sichtbarkeit statt Überzeugung. Die meisten Nutzerinnen aktualisieren automatisch und lesen die Notes nie vor dem Update; die Notes zählen am meisten für die Minderheit, die Updates manuell prüft, und für Reviewerinnen oder Presse, die einen Store-Eintrag überfliegen. Für dieses kleinere Publikum zu schreiben zahlt sich trotzdem aus, weil ein Eintrag mit einer echten Historie spezifischer, datierter Einträge sich wie eine aktiv gepflegte App liest, und ein Eintrag mit einem Jahr voller “Fehlerbehebungen und Leistungsverbesserungen” nicht, egal wie viel in dieser Zeit tatsächlich ausgeliefert wurde.

Was ist mit einem erzwungenen Update, bei dem die Note erklären muss, warum die Nutzerin keine Wahl hat?

Nenne den Grund und die Frist in der ersten Zeile, vor allem anderen, denn ein erzwungenes Update ist der eine Fall, in dem die Leserin genervt ist, bevor sie zu lesen beginnt. “Dieses Update ist nötig, damit deine Daten weiter synchronisiert werden. Aktualisiere bis zum [Datum], um Unterbrechungen zu vermeiden.” sagt in einem Satz, was zu tun ist und warum; diese Begründung unter drei Zeilen unzusammenhängender Feature-Notes zu begraben liest sich, als würde die App den unbequemen Teil verstecken.

FAQ

Sollten mobile Release Notes zum Web-Changelog desselben Releases passen? Dieselben zugrunde liegenden Änderungen abdecken, aber nicht Wort für Wort. Das Web-Changelog kann sich die volle Erklärung leisten; die mobile Note braucht dieselben Fakten komprimiert auf einen Satz mit dem Verb zuerst, was meist bedeutet, dass es eine Neufassung ist, keine Kopie.

Lohnt es sich, mobile Release Notes für jede unterstützte Sprache zu lokalisieren? Ja, mehr als bei einem Web-Changelog, weil der Store-Eintrag oft die einzige lokalisierte Fläche ist, die manche Nutzerinnen zwischen Sitzungen sehen, und beide Plattformen Release Notes pro Sprache unterstützen, ohne zusätzlichen Entwicklungsaufwand über die Übersetzung selbst hinaus.

Wie lang sollte eine mobile Release Note sein, wenn kein Limit zur Kürze zwingt? Trotzdem kurz. Die 4.000-Zeichen-Grenze bei iOS ist selten die eigentliche Einschränkung; das ist die Vorschau von 2-3 Zeilen, und über das hinaus zu schreiben, was diese Vorschau zeigt, bedeutet nur, dass weniger Leute den Teil lesen, der wichtig war.

Braucht eine Release Note eine Versionsnummer im sichtbaren Text? Nein. Der Store zeigt die Versionsnummer bereits neben den Notes. Sie im Text zu wiederholen verbraucht sichtbare Zeichen für Informationen, die die Leserin schon vor sich hat.

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.

Mehr bei changeloop: Vorlage für Release Notes, Changelog-Beispiele