App Store Release Notes Beispiele: „What's New“-Texte, die Nutzern sagen, was sich geändert hat (2026)

Gute App Store Release Notes beantworten eine einzige Frage: Was ist nach dem Update für mich anders? Die folgenden Beispiele für App Store Release Notes folgen alle demselben Muster. Beginnen Sie mit der Änderung, die der Nutzer bemerken wird, benennen Sie jede Fehlerbehebung konkret und lassen Sie alles weg, was er nicht sehen kann. Apples eigene Hinweise zum Feld What's New in This Version sagen dasselbe. Sie fragen nach neuen Funktionen, UI-Verbesserungen oder Fehlerbehebungen und empfehlen, Nutzern „die Einzelheiten der Änderungen, Verbesserungen oder Korrekturen in der Version“ mitzuteilen.

Welche Regeln gelten für Release Notes in App Store Connect und Google Play?

Apples „What's New“-Feld erlaubt 4.000 Zeichen und ist bei jeder Version nach der ersten Pflicht. Google Play erlaubt 500 Unicode-Zeichen pro Sprache und verbietet Werbeinhalte.

Stand Oktober 2026 sagt die Play Console-Hilfe: „Verwenden Sie Release Notes nicht für Werbezwecke oder um Nutzer zu Aktionen aufzufordern.“ Bei Apple gehören Marketingtexte stattdessen in Promotional Text. Dieses Feld erlaubt 170 Zeichen, erscheint über Ihrer Beschreibung, und Apple lässt Sie es aktualisieren, ohne eine neue Version einzureichen.

Wie sehen gute App Store Release Notes aus?

Gute Release Notes benennen die Situation, in der der Nutzer war, und das Ergebnis, das er jetzt bekommt. Die folgenden Beispiele stammen aus einer fiktiven Habit-Tracking-App. Die vagen Versionen sind die Art von Notes, die in letzter Minute geschrieben werden.

Wenn eine Korrektur zu technisch ist, um sie in einem Satz zu erklären, werden Nutzer sie wahrscheinlich nicht bemerken. Sie kann dann unter einer einzigen Zeile „Stabilitätsverbesserungen“ am Ende stehen. Richtlinie 2.3.12 erlaubt das für kleinere Korrekturen, aber nicht für echte Funktionsänderungen.

Gibt es eine Release-Notes-Vorlage, die ich wiederverwenden kann?

Ja. Eine wiederverwendbare Vorlage hat eine Überschrift und darunter die Abschnitte Neu, Verbessert und Behoben. Legen Sie sie im Repository neben das Changelog und füllen Sie sie aus, wenn Sie den Release-Branch erstellen – nicht erst, nachdem der Build hochgeladen ist.

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

Für Google Play kürzen Sie dieselben Notes auf die Überschrift plus die zwei oder drei wichtigsten Stichpunkte, damit sie in 500 Zeichen passen. Setzen Sie die Tags jeder Sprache in eigene Zeilen, zum Beispiel <en-US> und </en-US>. Lassen Sie bei Play die Schlusszeile weg, weil sie den Nutzer zu einer Aktion auffordert.

Wie macht man aus gemergten Pull Requests Release Notes?

Um aus gemergten Pull Requests Release Notes zu machen, filtern Sie Änderungen heraus, die Nutzer nicht sehen, und formulieren jede verbleibende Änderung als Symptom oder Ergebnis um. Gehen Sie bei jedem Release so vor.

1. Exportieren Sie die Titel der gemergten Pull Requests seit dem letzten Tag und löschen Sie alles, was Nutzer nicht sehen, etwa Refactorings, Dependency-Updates und CI-Änderungen.
2. Formulieren Sie jeden verbleibenden Punkt als Symptom oder Ergebnis um. Aus „Fix nil coordinator“ wird „Leerer Bildschirm nach der Anmeldung mit Apple behoben.“
3. Sortieren Sie die Punkte danach, wie viele Nutzer sie betreffen, nicht danach, wie viel Entwicklungsarbeit sie gekostet haben.
4. Erstellen Sie in App Store Connect die neue Version und löschen Sie den kopierten „What's New“-Text, bevor Sie die neuen Notes einfügen, denn die Metadaten der vorherigen Version werden übernommen.
5. Fügen Sie die Notes in jede unterstützte Lokalisierung ein, übersetzt oder zumindest in jeder Sprache geprüft, damit Nutzer in anderen Regionen nicht die Notes der letzten Version sehen.
6. Fügen Sie für Play die gekürzte Fassung innerhalb der Sprach-Tags ein und prüfen Sie, dass jede Sprache unter 500 Zeichen bleibt.
7. Lesen Sie die Notes einmal laut vor. Wenn ein Satz einen Entwickler braucht, der ihn erklärt, schreiben Sie ihn neu.

Was sollten Release Notes bei einem Hotfix sagen?

Release Notes für einen Hotfix sollten die fehlerhafte Version nennen, das jetzt behobene Symptom beschreiben und betroffenen Nutzern sagen, was nach dem Update passiert. Apple erlaubt kein Zurücksetzen auf eine frühere Version im App Store, daher wird eine Korrektur immer als neue Version ausgeliefert.

Ein Beispiel: „Problem in 3.4.0 behoben, durch das Erinnerungen bei manchen Nutzern nicht mehr ausgelöst wurden. Erinnerungen, die du vor dem Update eingestellt hast, laufen automatisch weiter.“ Betroffene Nutzer wissen, dass sie aktualisieren sollten, und nicht betroffene erkennen, dass die Korrektur sie nicht betrifft. Schieben Sie die Schuld nicht auf das Betriebssystem und versprechen Sie keine Termine für künftige Korrekturen. Wenn Sie Updates per phasenweiser Veröffentlichung ausliefern, begrenzt ein pausierter Rollout, wie viele Nutzer den fehlerhaften Build erhalten, während die Korrektur in der Prüfung ist. Wenn der Hotfix das Verhalten einer Funktion ändert, gehen Sie die App Store Einreichungs-Checkliste erneut durch, damit Notes, Screenshots und Prüfnotizen übereinstimmen.

Kann App Review ein Update wegen seiner Release Notes ablehnen?

Ja. Release Notes sind Metadaten, und die App Review Guidelines behandeln sie direkt. Richtlinie 2.3.12 besagt: „Apps müssen neue Funktionen und Produktänderungen in ihrem ‚What's New‘-Text klar beschreiben.“

Allgemeine Formulierungen sind für „einfache Fehlerbehebungen, Sicherheitsupdates und Leistungsverbesserungen“ erlaubt, aber „wesentlichere Änderungen müssen in den Notes aufgeführt werden“. Richtlinie 2.3.10 verbietet Namen oder Bilder anderer mobiler Plattformen in Metadaten, wozu auch „What's New“ gehört. Beschreiben Sie keine Funktionen hinter Feature-Flags und nichts, was nicht im eingereichten Build enthalten ist. Richtlinie 2.3.1(a) verlangt zusätzlich, dass neue Funktionen „im Abschnitt Notes for Review konkret beschrieben“ werden. Schritte für Prüfer und ein Demo-Konto gehören also dorthin, nicht in die öffentlichen Notes. Falls Sie doch eine Rückfrage zu Metadaten erhalten, erklärt unser Leitfaden zu App Store Ablehnungen beheben, wie Sie antworten.

Auf welche Probleme mit Release Notes sind andere Entwickler gestoßen?

Öffentlich gemeldete Fälle zeigen zwei Arten von Fehlern: Uploads, die wegen Überschreitung des Längenlimits eines Stores abgelehnt wurden, und Ablehnungen in der Prüfung, deren Bereinigungsanweisungen auch den „What's New“-Text umfassen.

• Play-Längenlimit in der CI. Ein GitHub-Issue in einer Flutter-Deployment-Vorlage berichtet von einem KI-generierten Changelog, das einen internen Test-Upload zu Google Play über fastlane mit folgender Meldung scheitern ließ: „The release created has notes in language ko-KR with length 612, which is too long (max: 500).“ Die Maintainer ergänzten ein Skript, das die Notes vor dem Upload kürzt: 480 Zeichen für Play und 3.800 Bytes für TestFlight, das sein Limit in Bytes misst.
• 2.3.10-Bereinigung inklusive „What's New“. Ein Entwickler veröffentlichte in den Apple Developer Forums eine Ablehnung nach Richtlinie 2.3.10, ausgelöst durch Nicht-iOS-Statusleisten in Screenshots. Apples nächste Schritte lauteten, „alle Vorkommen dieser Informationen aus Ihrer App und ihren Metadaten zu entfernen, einschließlich App-Beschreibung, Promotional Text, What's-New-Infos, Vorschauen und Screenshots“. Antworten rieten, die Screenshots neu aufzunehmen und jedes Metadatenfeld zu prüfen, Release Notes eingeschlossen.

Die Lehre daraus: Das Längenlimit ist mechanisch und scheitert lautstark beim Upload, während die Prüfregeln den Inhalt betreffen und für jedes Metadatenfeld gelten. Automatisieren Sie eine Zeichenprüfung und lesen Sie „What's New“ mit derselben Sorgfalt wie Ihre Screenshots.

Was sollten Sie vor dem Einreichen der Release Notes prüfen?

Prüfen Sie vor dem Einreichen, dass die Notes nur beschreiben, was im Build enthalten ist, die Limits jedes Stores einhalten und den Text der letzten Version in jeder Sprache ersetzen.

• Die Überschrift nennt die Änderung, die die meisten Nutzer bemerken werden.
• Jede wesentliche Funktion oder Produktänderung ist aufgeführt, wie Richtlinie 2.3.12 es verlangt.
• Jede Korrektur beschreibt ein Symptom, das der Nutzer gesehen hat, nicht internen Code.
• Keine Funktionen hinter Feature-Flags, keine Zukunftsversprechen, keine internen Ticketnummern, keine Namen anderer Plattformen.
• Der „What's New“-Text der vorherigen Version ist in jeder Lokalisierung gelöscht und ersetzt.
• Play-Notes liegen unter 500 Zeichen pro Sprache, sind in korrekte Sprach-Tags eingefasst und enthalten weder Werbung noch Handlungsaufforderungen.
• Marketingbotschaften sind bei Apple in Promotional Text verschoben.
• Wenn Sie auch Android-Tester haben, wurden dieselben Notes mit Ihrem Plan für geschlossene Tests abgeglichen.

Wenn Sie vor dem Einreichen ein zweites Paar Augen auf Ihre Update-Metadaten werfen lassen möchten, senden Sie Ihre Entwurfs-Notes und die Liste der Änderungen im Build an yagyeshsrbobde@gmail.com oder sehen Sie sich unsere Leistungen an.