Was sind Release Notes, und wo erscheinen sie?
Release Notes sind der kurze Text, der sagt, was sich in einer neuen Version deiner App geändert hat. In App Store Connect heißt das Feld What's New in this Version. Laut Apples Referenz zu den Versionsinformationen gehören dort die Änderungen dieser Version hinein, etwa neue Funktionen, Verbesserungen an der Oberfläche oder behobene Fehler.
Im App Store erscheint der Text an zwei Stellen: auf deiner Produktseite und im Tab für Updates, so steht es in Apples Leitfaden zur Produktseite. Im deutschen App Store trägt der Abschnitt die Überschrift „Neue Funktionen“, und über den Link „Versionsverlauf“ daneben kommst du zu den älteren Versionen. Das siehst du zum Beispiel beim Eintrag von Apples Pages im deutschen App Store. Bei Google Play tippst du die Notizen beim Vorbereiten eines Releases in ein eigenes Feld, in der englischen Play Console mit „What's new in this release?“ beschriftet. Google bittet laut der Hilfeseite der Play Console zu Releases darum, dort über die jüngsten Updates zu informieren.
Im Deutschen hörst du dafür viele Namen: Versionshinweise, Update Notes, Patch Notes, Changelog, Neuerungen oder einfach der Text unter „Neue Funktionen“. Gemeint ist immer dasselbe: eine Version, ein paar Zeilen, geschrieben für die Person, die die App benutzt, und nicht für das Team, das sie gebaut hat.
Alle Release Notes Beispiele auf dieser Seite haben wir selbst geschrieben, für erfundene Apps. Keines stammt aus einer echten App. Die einzige echte Notiz, die wir zitieren, ist mit App und Version gekennzeichnet.
Zeichenlimit für Release Notes im App Store und bei Google Play
Die beiden Stores geben dir sehr unterschiedlich viel Platz. Schreib zuerst die kurze Fassung und bau sie für den App Store aus, wenn das Release mehr verdient.
| Feld | Store | Limit | Was du wissen solltest |
|---|---|---|---|
| What's New in this Version (im deutschen Store „Neue Funktionen“) | App Store | 4.000 Zeichen | Für die erste Version einer App nicht verfügbar, für jede weitere Version Pflicht und lokalisierbar, laut Apples Versionsinformationen. |
| What's new in this release? | Google Play | 500 Unicode Zeichen pro Sprache | Google sagt, dass Release Notes nicht für Werbung gedacht sind und Nutzer nicht zu Aktionen auffordern sollen. Limit und Regel stehen in der Play Console Hilfe. |
| Werbetext (Promotional Text) | App Store | 170 Zeichen | Steht über deiner Beschreibung und lässt sich jederzeit ohne neue Version ändern, laut Apples Leitfaden zur Produktseite. Gut für Neuigkeiten, die nicht bis zum nächsten Release warten können. |
| Name des Releases | Google Play | Nur intern | Der Name des Releases erscheint nur in der Play Console, Nutzer sehen ihn nie. Für Notizen ist er also der falsche Ort. |
Apples Angaben haben wir am 4. November 2026 geprüft, Googles zuletzt am 17. Oktober 2026. In Apples Liste der Pflichtfelder sowie der lokalisierbaren und bearbeitbaren Eigenschaften ist What's New als Pflicht für Versionsupdates und als lokalisierbar markiert, aber nicht als bearbeitbar ohne neue Version. Prüf den Text also gründlich, bevor du einreichst.
Wer Release Notes überhaupt liest
Weniger Leute, als du hoffst, aber genau die, auf die es ankommt. Apps aus dem App Store werden auf iPhone und iPad standardmäßig automatisch aktualisiert, wie Apples Supportseite zum Aktualisieren von Apps erklärt. Viele Nutzer bekommen die neue Version also, ohne die Liste der Updates je zu öffnen. Wer trotzdem liest, gehört zu deinen treuesten Nutzern: die Person, die auf einen bestimmten Bugfix wartet, die Person, die überlegt, ob sie zurückkommt, und die Person, die gerade auf ein Problem gestoßen ist.
Auch Leute, die die App noch gar nicht installiert haben, lesen mit. Der Text zu den neuen Funktionen steht auf der Produktseite, und wer zwei Apps vergleicht, sieht dort, wann deine zuletzt aktualisiert wurde und ob die Notizen nach einem Team klingen, dem die App wichtig ist. Eine Seite voller identischer Einzeiler sagt diesem Besucher sehr wenig. Wie oft andere Apps überhaupt Updates bringen, zeigt unser Überblick, wie oft Apps aktualisiert werden.
Auch das Team von App Review liest die Notizen. Richtlinie 2.3.12 in Apples App Review Guidelines verlangt, dass Apps neue Funktionen und Änderungen am Produkt im What's New Text klar beschreiben. Dieselbe Regel erlaubt für einfache Bugfixes, Sicherheitsupdates und Verbesserungen der Leistung eine allgemeine Beschreibung, sagt aber, dass größere Änderungen aufgeführt werden müssen. Wie so eine allgemeine Zeile aussieht, zeigt Apples eigene App Pages: Für Version 15.4.2 steht im deutschen App Store nur der Satz „Dieses Update enthält Fehlerbehebungen und Leistungsverbesserungen“, gelesen am 4. November 2026 im Versionsverlauf von Pages. Bei einem Release, das etwas Neues bringt, reicht so ein Satz nicht mehr. Welche Gründe für Ablehnungen sonst häufig sind, steht in unserem Ratgeber zu Gründen für eine Ablehnung im App Store.
Bleibt noch dein eigenes Team. Wer Supportanfragen beantwortet, den Newsletter schreibt oder die Social Media Kanäle betreut, fängt bei den Release Notes an. Klare Notizen ersparen allen die Rückfrage bei der Entwicklung, was eigentlich ausgeliefert wurde.
Release Notes Beispiele für normale Updates
Diese vier decken die meisten Releases ab. Jedes Beispiel ist für eine erfundene App geschrieben und bleibt unter 500 Zeichen. Setz deine eigenen Funktionen und Zahlen ein. Im Store gehört jeder Punkt in eine eigene Zeile.
Bugfix Release
„Behoben: Die App stürzte ab, wenn du ohne Verbindung eine geteilte Liste geöffnet hast. Behoben: Erinnerungen kamen nach der Zeitumstellung eine Stunde zu spät. Behoben: Das Widget zeigte die Aufgaben von gestern, bis du die App geöffnet hast. Danke an alle, die uns die Fehler gemeldet haben. So konnten wir sie schnell finden.“ Warum das funktioniert: Jeder Fehler ist so beschrieben, wie ihn ein Nutzer selbst erzählen würde. Wer ihn erlebt hat, weiß sofort, dass dieses Update für ihn ist.
Eine große neue Funktion
„Neu: gemeinsame Budgets. Lade deinen Partner, deine Partnerin oder jemanden aus deiner WG zu einem Budget ein, und ihr seht beide jede Ausgabe, sobald sie eingetragen ist. Private Budgets behält trotzdem jeder für sich. So geht es: Budget öffnen, auf Teilen tippen, Einladung senden. Außerdem in dieser Version: eine schnellere Suche und ein Fix für doppelte Bankimporte.“ Warum das funktioniert: Die eine Funktion bekommt die erste Zeile und die Anleitung, die Kleinigkeiten warten bis zum Schluss.
Mehrere kleine Verbesserungen
„Fünf Kleinigkeiten, die du dir gewünscht hast. 1. Sortiere Notizen nach dem Datum der letzten Änderung. 2. Hefte bis zu drei Notizen oben an. 3. Exportiere eine Notiz über das Menü Teilen als PDF. 4. Größere Tasten in der Symbolleiste. 5. Der Dunkelmodus folgt jetzt dem Zeitplan deines iPhones.“ Warum das funktioniert: Eine nummerierte Liste mit je einem Satz ist schnell überflogen, und die erste Zeile zeigt, dass Wünsche gelesen werden.
Update für mehr Tempo
„In diesem Update geht es nur um Tempo. Auf älteren Geräten startet die App jetzt in etwa der halben Zeit. Fotos laden im Hintergrund weiter hoch, du kannst also den Bildschirm sperren. Der Download ist 30 MB kleiner. Neue Funktionen gibt es diesmal keine, dafür eine schnellere App.“ Warum das funktioniert: Der Text nennt Zahlen statt nur das Wort schneller. Veröffentliche aber nur Werte, die du wirklich gemessen hast.
Release Notes Beispiele für große Änderungen
Bei großen Änderungen schaden vage Notizen am meisten. Diese Releases bemerken die Leute, also sag klar, was sich geändert hat und was gleich geblieben ist.
Redesign
„Neues Aussehen, dieselbe App. Aus vier Tabs werden drei: Start, Suche und Mediathek. Deine Downloads findest du jetzt in der Mediathek. Die Einstellungen liegen hinter deinem Profilbild oben rechts. Entfernt wurde nichts, und deine Playlists sind genau da, wo du sie gelassen hast. Deine Meinung kannst du uns unter Einstellungen > Feedback senden schicken.“ Warum das funktioniert: Der Text beantwortet die erste Frage nach jedem Redesign, nämlich wo eine vertraute Taste geblieben ist.
Preisänderung
„Zwei Änderungen bei den Plänen. Der kostenlose Plan enthält jetzt 3 Projekte statt 1. Der Preis für Pro ändert sich für neue Abonnenten am 1. März. Hast du schon ein Abo, bleibt dein Preis gleich. Außerdem: Vorlagen für Projekte und ein Fix für verzögerte Synchronisierung bei langsamer Verbindung.“ Warum das funktioniert: Der Text sagt, wer betroffen ist, wer nicht und ab wann, und nennt keinen Betrag, der in der Währung eines anderen Landes falsch wäre.
Entschuldigung nach einem Ausfall
„Version 4.2 ist uns misslungen. Etwa einen Tag lang konnten sich einige von euch nicht anmelden, und ein paar haben Entwürfe verloren, die noch nicht synchronisiert waren. Diese Version behebt den Fehler bei der Anmeldung und holt diese Entwürfe beim ersten Öffnen aus unserem Backup zurück. Fehlt dir noch etwas, schreib an help@example.com, und ein Mensch antwortet dir. Es tut uns leid.“ Warum das funktioniert: Was kaputt war, wen es traf, was behoben ist und wo es Hilfe gibt, ohne Ausreden.
Eine Funktion fällt weg
„Wichtig: Mit dieser Version entfällt der Export als CSV im alten Format. Der neue Export hat dieselben Spalten und zusätzlich die Kategorien, und er öffnet sich in denselben Tabellenprogrammen. Exporte, die du schon gespeichert hast, sind nicht betroffen. Brauchst du das alte Format für deine Abläufe, schreib uns vor dem Update unter Einstellungen > Feedback.“ Warum das funktioniert: Über eine entfernte Funktion ärgern sich Leute am meisten, wenn sie es selbst merken. Deshalb steht sie ganz oben, zusammen mit einer Alternative.
Sicherheitsupdate
„Dieses Update behebt ein Sicherheitsproblem in der Art, wie die App deine Anmeldedaten auf dem Gerät gespeichert hat. Wir haben keine Hinweise darauf, dass jemand auf ein Konto zugegriffen hat. Nach dem Update musst du dich einmal neu anmelden. Wir empfehlen, diese Version noch heute zu installieren.“ Warum das funktioniert: Apple erlaubt für Sicherheitsupdates eine allgemeine Zeile, aber wer die zusätzliche Anmeldung erklärt, verhindert eine Welle von Mails an den Support.
Release Notes nach Art der App und Anlass
Die Regeln gelten für jede App. Ein Spiel, eine App mit Abo und eine ganz neue App haben aber jeweils etwas Eigenes, das sitzen muss.
Erstes Release einer neuen App
„Willkommen bei Version 1.0. Zeichne deine Läufe per GPS auf, sieh Tempo und Strecke auf einem Bildschirm und speichere jede Route in einem privaten Verlauf. Ein Konto brauchst du nicht. Das ist unser erstes Release, darum lesen wir jede Nachricht. Was wir als Nächstes bauen sollen, sag uns unter Einstellungen > Kontakt.“ Warum das funktioniert: Eine erste Version hat keine Änderungen, also sagt der Text mit drei Verben, was die App tut, und lädt zu Feedback ein. Nutze ihn bei Google Play. Im App Store gibt es für die erste Version kein Feld für What's New. Wie du den Start selbst ankündigst, zeigen unsere Beispiele für App Launch Ankündigungen.
Update zur Saison
„Winterupdate. Neu: eine Geschenkliste, die du mit deiner Familie teilen kannst, mit einem Häkchen, das schon Gekauftes ausblendet. Neu: drei Winterthemen für dein Widget auf dem Homescreen. Die Geschenkliste bleibt das ganze Jahr unter Listen in der App. Außerdem behoben: Preise erscheinen nach einem Wechsel der Region jetzt in deiner Landeswährung.“ Warum das funktioniert: Bei Funktionen zur Saison fragen sich Leute, was im Januar verschwindet, und der Text beantwortet genau das.
Neue Version eines Spiels
„Saison 5 ist live. Erkunde den Eishafen, eine neue Region mit 20 Levels und einem Boss, den du auf treibendem Eis bekämpfst. Neue Waffe: die Harpune, freigeschaltet ab Level 8. Tägliche Quests bringen am Wochenende doppelte Münzen. Balance: Die Abklingzeit des Schilds steigt von 6 auf 8 Sekunden. Behoben: Einladungen liefen nach einer Minute ab.“ Warum das funktioniert: Spieler lesen zuerst nach neuen Inhalten, dann nach Änderungen an der Balance mit genauen Zahlen, dann nach Fixes.
App mit Abo
„Neu für Abonnenten: Workouts herunterladen und ohne Verbindung nutzen, dazu ein Wochenplan, der sich anpasst, wenn du einen Tag auslässt. Kostenlos für alle: eine Bibliothek mit 12 kurzen Dehnroutinen. Abonnenten bekommen die neuen Funktionen automatisch. An deiner Abrechnung ändert sich nichts.“ Warum das funktioniert: Der Text trennt, was zahlende Mitglieder bekommen und was kostenlos ist, und nimmt die Sorge, die jeder Abonnent hat, sobald ein Update von Plänen spricht.
Update für Barrierefreiheit
„Bessere Unterstützung für VoiceOver und größere Schrift. Jede Taste im Player hat jetzt eine Beschriftung für VoiceOver. Text folgt deiner Schriftgröße im System bis zur größten Stufe, ohne abgeschnitten zu werden. Diagramme haben eine Zusammenfassung als Text, die vorgelesen werden kann. Einnahmen und Ausgaben erkennst du nicht mehr nur an der Farbe. Ist etwas noch schwer zu bedienen, sag es uns bitte.“ Warum das funktioniert: Der Text nennt die genauen Einstellungen, auf die Leute angewiesen sind. So sehen sie, ob die App jetzt für sie funktioniert.
Weitere Release Notes Beispiele: Hotfix, Beta und Migration
Sechs Releases, die nicht ins übliche Schema aus neu, verbessert und behoben passen. Auch hier bleibt jedes unter 500 Zeichen.
Hotfix am selben Tag
„Version 2.8.1 behebt einen Fehler aus dem gestrigen Update: Auf manchen Geräten tat die Kamerataste nichts. Wenn das Scannen bei dir nicht mehr ging, funktioniert es jetzt wieder. Verloren gegangen sind keine Belege, denn solange die Taste nicht reagierte, wurde auch nichts gespeichert. Sorry für den verlorenen Tag.“ Warum das funktioniert: Der Text nennt die Version, die den Fehler brachte, sagt, wen er traf, und beantwortet die Frage nach den Daten, bevor jemand sie stellen muss.
Funktion als Beta
„Neu, als Beta: Sprachnotizen. Halte die Mikrofontaste gedrückt, um aufzunehmen, und die App schreibt eine Abschrift unter die Aufnahme. Vorerst klappt das nur auf Englisch, und Namen versteht sie manchmal falsch. Einschalten kannst du sie unter Einstellungen > Betafunktionen. Sag uns, wo die Abschrift danebenliegt. Außerdem behoben: Tags mit Leerzeichen werden jetzt gespeichert.“ Warum das funktioniert: Die Funktion steckt in diesem Build und der Nutzer schaltet sie selbst ein. Die Notiz stimmt also, und die Grenzen stehen gleich dabei.
Update, bei dem der Nutzer etwas tun muss
„Wichtig: Beim ersten Öffnen dieser Version wandelt die App deine Bibliothek in ein neues Format um. Bei einer großen Bibliothek dauert das bis zu einer Minute. Lass die App geöffnet, bis der Fortschrittsbalken voll ist. Gelöscht wird nichts, und die alte Kopie bleibt 30 Tage auf deinem iPhone. Danach ist die Suche etwa dreimal so schnell.“ Warum das funktioniert: Die Anweisung steht vorn, die Angst vor Datenverlust wird beantwortet, und der Gewinn kommt zum Schluss.
Jetzt auf einem größeren Bildschirm
„Jetzt auch für das iPad. Im Querformat bekommst du zwei Spalten: links die Notizbücher, rechts die Seite. Zieh ein Foto aus einer anderen App hinein. Mit Tastatur bedienbar, inklusive Kurzbefehlen für neue Seite, Suche und Fettdruck. Deine Notizen vom iPhone werden synchronisiert, sobald du dich zum ersten Mal anmeldest.“ Warum das funktioniert: Ein neues Gerät ist eine Funktion, und der Text sagt, was darauf anders ist, statt nur, dass es die App jetzt dafür gibt.
Neue Inhalte ohne neue Funktionen
„40 neue Rezepte für den Herbst, davon 12 in unter 20 Minuten. Neue Sammlung: Gerichte aus einem Topf. Außerdem haben wir die Kochzeit der Linsensuppe korrigiert (35 Minuten, nicht 15), nachdem uns drei von euch geschrieben hatten. An der Bedienung der App ändert sich nichts.“ Warum das funktioniert: In einer App, die man wegen ihrer Inhalte öffnet, sind die Inhalte das Release, und auch sie verdienen Zahlen.
Notizen für eine TestFlight Beta
„Bitte teste in Build 412 den neuen Checkout. 1. Leg zwei Artikel in den Warenkorb und bezahle mit der Testkarte. 2. Schließ die App mitten in der Zahlung und öffne sie wieder. 3. Probier einen Rabattcode aus. Bekanntes Problem: Die Quittung per E-Mail wird noch nicht verschickt. Feedback schickst du, indem du in der App einen Screenshot machst.“ Warum das funktioniert: Tester bekommen Aufgaben, Nutzer im Store bekommen ein Changelog. In Apples Überblick zu TestFlight steht, dass die Testinformationen eine Erklärung der zu testenden Funktionen enthalten können und dass Tester ab TestFlight 2.3 auf iOS, macOS und visionOS Feedback auch per Screenshot direkt in der Beta App senden können.
Release Notes Vorlage zum Ausfüllen
Nimm nur die Zeilen, die passen. Ein Release mit einem einzigen Fix braucht eine einzige Zeile. Ersetze die Wörter in eckigen Klammern.
| Zeile | Zum Ausfüllen | Wann du sie nutzt |
|---|---|---|
| Thema | In dieser Version geht es um [eine Idee in drei oder vier Wörtern]. | Wenn das Release einen klaren Schwerpunkt hat, etwa Tempo oder Teilen. Bei einer bunten Mischung lass sie weg. |
| Neu | Neu: Du kannst jetzt [was tun] unter [wo in der App]. | Eine Funktion, die es vorher nicht gab. Sag, wo man sie findet. |
| Verbessert | Verbessert: [Bildschirm oder Funktion] ist jetzt [messbare Änderung]. | Etwas Bestehendes, das besser wurde. Nenn eine Zahl, wenn du gemessen hast. |
| Behoben | Behoben: [was schiefging, in den Worten des Nutzers], wenn [Situation]. | Jeder Fehler, den ein Nutzer bemerkt haben könnte. |
| Geändert oder entfernt | Geändert: [Funktion] liegt jetzt unter [neuer Ort]. Entfernt: [Funktion], nutze stattdessen [Alternative]. | Alles, wonach ein wiederkehrender Nutzer sucht und es nicht mehr findet. |
| Danke | Du hast dir [Wunsch] gewünscht. Jetzt ist es da. | Wenn Feedback zur Änderung geführt hat. |
| Hilfe | Stimmt etwas nicht? Schreib an [Adresse des Supports]. | Nach einem holprigen Release oder bei einer ersten Version. |
Die Labels Neu, Geändert, Entfernt und Behoben folgen den Arten von Änderungen bei Keep a Changelog, einer veröffentlichten Konvention für Changelogs. Dort heißen sie Added, Changed, Removed und Fixed.
Was in Release Notes gehört: Checkliste nach Größe des Releases
Die Vorlage oben zeigt, welche Zeilen du nutzen kannst. Diese Tabelle sagt, welche davon ein bestimmtes Release braucht. Apple empfiehlt für das Feld in seiner Referenz zu den Versionsinformationen ausführliche Angaben, damit Nutzer die Einzelheiten der Änderungen, Verbesserungen oder Fixes kennen. Wie viel Detail richtig ist, hängt von der Art des Releases ab.
| Art des Releases | Muss rein | Rein, wenn es stimmt | Lass weg |
|---|---|---|---|
| Patch oder Hotfix | Jeder Fehler, auf den ein Nutzer stoßen konnte, benannt nach dem, was er gesehen hat. Repariert der Patch ein frisches Update, auch die Version, die den Fehler brachte. | Wer betroffen war und ob Daten verloren gingen oder wiederhergestellt wurden. | Die Ursache in der Sprache der Entwicklung, Ticketnummern und den Namen der schuldigen Bibliothek. |
| Release mit neuer Funktion | Die neue Funktion in der ersten Zeile: was man damit tun kann und wo in der App sie liegt. | Dass Nutzer sie sich gewünscht haben. Ob sie kostenlos ist oder nur für Abonnenten. | Funktionen, die zwar gebaut, für die meisten Leute aber noch abgeschaltet sind. |
| Redesign oder große Version | Was umgezogen ist, was entfernt wurde und was man stattdessen nutzt. | Wie man Feedback schickt, denn ein Redesign erzeugt immer welches. | Adjektive wie frisch oder neu gedacht statt der Angabe, wohin etwas gewandert ist. |
| Sicherheit oder Datenschutz | Dass das Update ein Sicherheitsproblem behebt, und alles, was der Nutzer tun muss, etwa sich neu anmelden. | Ob es Hinweise auf Missbrauch gibt, aber nur, wenn du es wirklich weißt. | Technische Details, mit denen jemand Leute angreifen könnte, die noch auf der alten Version sind. |
| Änderung bei Preis oder Plan | Wer betroffen ist, wer nicht und ab welchem Datum. | Was bestehende Abonnenten behalten und wo sie ihr Abo verwalten. | Einen Betrag in einer Währung, der für alle falsch ist, die in einer anderen zahlen. |
| Update der Inhalte | Was dazugekommen ist, mit einer Zahl: Levels, Rezepte, Lektionen, Karten. | Korrekturen an bestehenden Inhalten, wenn Leute sie gemeldet haben. | Eine Liste aller Einträge, wenn eine Zahl und zwei Beispiele dasselbe sagen. |
Passt ein Release in zwei Zeilen, nutze beide: Ein Release mit neuer Funktion, das zugleich ein Sicherheitsproblem behebt, beginnt mit der Funktion und nennt den Fix trotzdem klar.
Ein Release, vier Texte
Hier dasselbe erfundene Update, Version 3.4 einer App für Haushaltsbudgets, zugeschnitten auf jeden Ort, an dem es erscheinen muss. Alle vier zusammen zu schreiben dauert zehn Minuten und hält sie einheitlich.
| Wo | Wie viel Platz | Beispiel |
|---|---|---|
| App Store, Neue Funktionen | 4.000 Zeichen | Neu: gemeinsame Budgets. Lade deinen Partner, deine Partnerin oder jemanden aus deiner WG zu einem beliebigen Budget ein, und ihr seht beide jede Ausgabe, sobald sie eingetragen ist. Private Budgets kann trotzdem jeder für sich behalten. So startest du: Budget öffnen, auf Teilen tippen, Einladung senden. Verbessert: Die Suche schaut jetzt auch in Notizen und zeigt Treffer schon beim Tippen. Verbessert: Der Monatsbericht lädt in etwa einer Sekunde. Behoben: Bankimporte erzeugen nach einer fehlgeschlagenen Synchronisierung keine doppelten Einträge mehr. Behoben: Das Widget aktualisiert sich jetzt um Mitternacht. Gemeinsame Budgets hast du dir dieses Jahr öfter gewünscht als alles andere. Danke fürs Nachhaken. |
| Google Play, Release Notes | 500 Zeichen pro Sprache | Neu: gemeinsame Budgets. Lade deinen Partner, deine Partnerin oder jemanden aus deiner WG ein, und ihr seht jede Ausgabe, sobald sie eingetragen ist. Verbessert: Die Suche schaut auch in Notizen. Verbessert: schnellerer Monatsbericht. Behoben: doppelte Bankimporte und ein Widget, das sich nicht aktualisiert hat. |
| Werbetext im App Store | 170 Zeichen | Neu in 3.4: gemeinsame Budgets. Lade deinen Partner oder deine WG ein, und ihr seht jede Ausgabe, sobald sie eingetragen ist. |
| Text für einen Social Post | Je nach Netzwerk | Gemeinsame Budgets sind da. Lade eine Person ein, und jede Ausgabe erscheint bei euch beiden, sobald sie eingetragen ist. Version 3.4 gibt es ab sofort im App Store. |
Wie viel Platz jedes Netzwerk für den Text eines Posts lässt, steht in unserer Übersicht der Zeichenlimits auf Social Media.
Schwache Release Notes umgeschrieben: vorher und nachher
Fünf Notizen von der Sorte, die den Tab für Updates füllt, jeweils neben einer Fassung, mit der ein Nutzer etwas anfangen kann.
| Vorher | Nachher | Was sich geändert hat |
|---|---|---|
| Fehlerbehebungen und Leistungsverbesserungen. | Behoben: Die App fror ein, wenn du ein Foto gedreht hast. Lange Alben scrollen auf älteren Geräten flüssiger. | Der Text nennt den einen Fehler und die eine Stelle, die schneller wurde. Er ist immer noch nur zwei Zeilen lang. |
| Wir aktualisieren die App regelmäßig, um sie für dich besser zu machen. | Diese Version bringt einen Schlaftimer im Player. Du findest ihn unter den drei Punkten, während eine Geschichte läuft. | Er sagt, was in diesem Build steckt. Die erste Notiz könnte unter jeder Version jeder App stehen. |
| OAuth Token Refresh implementiert, Race Condition in der Sync Queue behoben (#4821). | Du wirst nicht mehr alle paar Tage abgemeldet. Behoben: Eine Notiz konnte doppelt gespeichert werden. | Dieselben zwei Fixes, in den Worten, die der Nutzer auf seinem Bildschirm sieht. |
| RIESIGES Update!!! Du wirst es LIEBEN!!! | Neu: Rechnungen mit Freunden teilen. Füg Leute zu einer Ausgabe hinzu, und die App rechnet aus, wer wem was schuldet. | Die Funktion überzeugt von selbst. |
| Neu: Dunkelmodus, Widgets, Familienfreigabe, Export, Tags, Themes und 23 Fixes. | Neu: Familienfreigabe. Lade bis zu fünf Personen in deine Bibliothek ein. Ebenfalls neu: Dunkelmodus, Widgets, Tags und Export. Behoben: 23 Fehler, darunter der Absturz bei der Suche. | Die größte Änderung bekommt eigene Sätze, der Rest folgt nach Wichtigkeit. |
Release Notes in zehn Minuten schreiben
Erledige das, während der Build verarbeitet wird, und nicht erst, wenn der Knopf zum Einreichen schon vor dir liegt.
- Schritt 1
Alles auflisten, was ausgeliefert wird
Kopier die zusammengeführten Änderungen dieser Version aus deinem Tracker. Diese Liste ist nur für dich, und keine ihrer Formulierungen landet im Store.
- Schritt 2
Streichen, was kein Nutzer bemerken kann
Refactorings, aktualisierte Abhängigkeiten und Änderungen am Build fliegen raus. Übrig bleiben neue Dinge, geänderte Dinge und Fixes für Fehler, auf die jemand stoßen konnte.
- Schritt 3
Nach Wichtigkeit sortieren und in die Sprache der Nutzer übersetzen
Stell die größte Änderung an den Anfang. Diese Reihenfolge empfiehlt Apples Leitfaden zur Produktseite für What's New. Schreib zu jeder Zeile, was die Person jetzt tun kann oder was nicht mehr schiefgeht.
- Schritt 4
Eine Fassung für Google Play kürzen
Kürze bewusst auf 500 Zeichen und lass die erste Zeile vollständig. Zähl nach, bevor du den Text in die Play Console einfügst.
- Schritt 5
Zweimal Korrektur lesen
What's New steht nicht auf Apples Liste der Felder, die du ohne neue Version bearbeiten kannst. Ein Tippfehler bleibt also bis zum nächsten Release auf deiner Produktseite.
Release Notes in App Store Connect eintragen und ändern
Wohin der Text gehört, was du nach dem Einreichen noch ändern kannst und wie Teams, die oft ausliefern, das Webformular ganz umgehen. Geprüft an Apples Hilfeseiten am 4. November 2026. Die Namen von Feldern und Status nennen wir so, wie sie in der englischen Oberfläche heißen.
- Schritt 1
Die neue Version anlegen
Wähle unter Apps die App aus, klick auf das Pluszeichen neben der Plattform und gib die neue Versionsnummer ein. Apples Seite zum Anlegen einer neuen Version ergänzt, dass die aktuelle Version den Status Ready for Distribution haben muss, bevor du die nächste anlegen kannst, und dass das nur die Rollen Account Holder, Admin, App Manager und Marketing dürfen. Wer die Notizen schreibt, ist also nicht unbedingt die Person, die den Build hochlädt.
- Schritt 2
Jedes übernommene Feld durchlesen
Laut derselben Seite werden die Metadaten der aktuellen Version automatisch in die neue Version übernommen. Geh die Versionsseite vor dem Speichern Feld für Feld durch, What's New eingeschlossen, damit nichts aus dem letzten Release versehentlich noch einmal eingereicht wird.
- Schritt 3
What's New für jede Sprache schreiben
What's New ist ein lokalisierbares Feld mit bis zu 4.000 Zeichen, laut Apples Versionsinformationen. Wechsle die Sprache über das Menü auf der Versionsseite und füg jede Übersetzung in ihr eigenes Feld ein. Eine Sprache, die du auslässt, zeigt die Notizen deiner Hauptsprache.
- Schritt 4
Notizen ändern, während die Version in der Prüfung ist
Willst du eingereichte Notizen noch ändern, nimm die Einreichung aus der Prüfung. Das geht, solange die Version einen dieser fünf Status hat: Waiting for Export Compliance, Waiting for Review, In Review, Pending Developer Release oder Pending Apple Release. Du brauchst dafür die Rolle Account Holder, Admin oder App Manager. Danach steht die Version auf Developer Rejected. Ändere die Notizen und reiche neu ein. Apple weist darauf hin, dass die Prüfung dann von vorn beginnt. Plan also eine weitere Runde vor deinem Releasetermin ein. Mit wie viel Zeit du rechnen solltest, steht in unserem Artikel zur Dauer der Prüfung im App Store.
- Schritt 5
Notizen korrigieren, wenn die Version live ist
In Apples Liste der Pflichtfelder sowie der lokalisierbaren und bearbeitbaren Eigenschaften ist What's New als Pflicht und lokalisierbar markiert, aber nicht als bearbeitbar. Eine Version, die live ist, behält also ihre Notizen. Korrigier den Fehler in den Notizen der nächsten Version. Bis dahin hilft der Werbetext, die Zeile mit 170 Zeichen über deiner Beschreibung, die du jederzeit ändern kannst.
- Schritt 6
Die Notizen per Skript setzen
Teams, die jede Woche ausliefern, öffnen das Formular oft gar nicht. Die Anfrage der App Store Connect API zum Ändern einer Lokalisierung der App Store Version nimmt für jede Sprache ein Attribut whatsNew an. Die Action deliver von fastlane liest die Notizen aus einer Datei release_notes.txt in einem Ordner pro Sprache und kann über den besonderen Sprachcode default einen Standardtext für jede Sprache setzen, die keine eigene Datei hat. In beiden Fällen gelten dieselben Regeln: ein Text pro Sprache, geschrieben für Nutzer.
Video: ein App Update in App Store Connect einreichen
Wenn du noch nie eine zweite Version veröffentlicht hast, zeigt dir dieses Video, wo das Formular für die Version liegt, bevor du auch nur ein Wort hineinschreibst.
Release Notes: was du tun und was du lassen solltest
| Tu das | Lass das | Warum |
|---|---|---|
| Änderungen nach Wichtigkeit ordnen, die größte zuerst. | Mit der Versionsnummer, einer Begrüßung oder einem Witz anfangen. | Nach Wichtigkeit zu ordnen ist Apples eigener Rat für What's New in seinem Leitfaden zur Produktseite. |
| Die Funktion nennen, die du hinzugefügt hast. | „Fehlerbehebungen und Leistungsverbesserungen“ unter ein Release schreiben, das etwas Neues bringt. | Richtlinie 2.3.12 erlaubt eine allgemeine Zeile nur für einfache Fixes, Sicherheitsupdates und Arbeit an der Leistung. |
| Beschreiben, was heute in diesem Build steckt. | Funktionen ankündigen, die noch abgeschaltet sind oder erst später kommen. | Abschnitt 2.3 derselben Richtlinien verlangt Metadaten, die die App korrekt wiedergeben, und Nutzer suchen nach dem, was du versprochen hast. |
| Bei Google Play bei reiner Information bleiben. | In den Release Notes bei Google Play um Bewertungen bitten oder für ein Angebot werben. | Google bittet Entwickler in der Play Console Hilfe, Release Notes nicht für Werbung zu nutzen und keine Handlungen von Nutzern einzufordern. |
| Sagen, wenn Feedback zu einer Änderung geführt hat. | Einen Fix verschweigen, weil er zugibt, dass es einen Fehler gab. | Apple empfiehlt, mit What's New zu zeigen, dass du zugehört hast, wenn eine Funktion oder ein Fix auf Feedback zurückgeht. |
| In den Worten schreiben, die auf dem Bildschirm des Nutzers stehen. | Ticketnummern, Commit Messages oder interne Codenamen einfügen. | Keep a Changelog sagt dasselbe über Changelogs: Sie werden für Menschen geschrieben, und Commit Logs darin sind eine schlechte Idee. |
| Genaue Preise weglassen. | Einen Betrag in Euro oder Dollar in Notizen schreiben, die jedes Land sieht. | Apple gibt diesen Rat für die Beschreibung der App: Ein Preis im Text stimmt womöglich nicht in allen Regionen. Für Notizen gilt dieselbe Logik. |
| Eine Fassung für Google Play mit höchstens 500 Zeichen schreiben. | Eine lange Notiz aus dem App Store in die Play Console kopieren und abschneiden, was nicht passt. | Der Schnitt landet meist mitten im Satz. Schreib die kurze Fassung mit Absicht. |
Release Notes auf Deutsch und in anderen Sprachen
In beiden Stores kannst du für jede Sprache eigene Notizen schreiben. Unübersetzte Notizen in einem übersetzten Eintrag fallen Nutzern sofort auf.
- Schritt 1
Wissen, was passiert, wenn du es auslässt
Im App Store lässt sich What's New lokalisieren. Wenn du eine Sprache hinzufügst, übernehmen ihre Eigenschaften und Screenshots die Werte deiner Hauptsprache, mit Ausnahme von Beschreibung und Keywords, so steht es auf Apples Seite zum Lokalisieren der App Informationen. Ein deutscher Eintrag ohne deutsche Notizen zeigt also deine englischen.
- Schritt 2
Den Ausgangstext übersetzbar schreiben
Kurze Sätze, je ein Gedanke, keine Redewendungen und keine Wortspiele. Eine Zeile wie „Behoben: Absturz beim Öffnen einer geteilten Liste ohne Verbindung“ lässt sich sauber übersetzen. Ein Witz über den Fehler fast nie.
- Schritt 3
Dieselben Namen wie in der übersetzten App verwenden
Heißt der Button in der deutschen Oberfläche Teilen, müssen auch die deutschen Notizen Teilen sagen. Gib deinem Übersetzer die Texte der Oberfläche mit, sonst schicken die Notizen Leute auf die Suche nach einer Taste, die anders heißt.
- Schritt 4
Unter dem Limit von Google Play Luft lassen
Google Play erlaubt 500 Zeichen pro Sprache, und der Text jeder Sprache steht zwischen eigenen Sprachtags auf separaten Zeilen, wie die Play Console Hilfe zeigt. Eine Übersetzung kann länger werden als das Englische. Bleib mit dem englischen Text also deutlich unter 500.
- Schritt 5
Mit Vorsicht wiederverwenden
Die Play Console kann die Notizen und Übersetzungen eines früheren Releases zum Bearbeiten in das Feld kopieren. Beschrieben ist das auf derselben Hilfeseite der Play Console. Bei einem Wartungsrelease spart das Zeit, aber prüf jede Sprache vor dem Veröffentlichen, sonst kündigst du die Funktion vom letzten Monat noch einmal an.
Release Notes bei Google Play zu lang? Länge, Sprachtags und Formatierung
Google Play gibt dir 500 Unicode Zeichen pro Sprache, laut Play Console Hilfe, zuletzt von uns am 17. Oktober 2026 gelesen. Das ist ein Achtel des Platzes im App Store, und deshalb passen Notizen meist aus einem einfachen Grund nicht: Jemand hat den Text aus dem App Store komplett eingefügt. Das Limit zählt jede Sprache für sich. Eine lange deutsche Übersetzung verbraucht nichts vom englischen Kontingent, muss aber in ihre eigenen 500 passen.
Fügst du mehrere Sprachen auf einmal ein, zählt das Format genauso wie die Länge. Googles Hilfeseite zeigt die Notizen jeder Sprache zwischen einem öffnenden und einem schließenden Sprachtag, jedes Tag auf einer eigenen Zeile, und sagt, dass die Notizen selbst über mehrere Zeilen gehen dürfen. Prüf vor dem Kürzen, ob jede eingefügte Sprache beide Tags hat und nichts außerhalb davon steht.
Um eine Notiz auf 500 Zeichen zu bringen, ohne das Wichtige zu verlieren, geh in dieser Reihenfolge vor. Lass die erste Zeile ganz, denn sie trägt den Grund für das Update. Fass die Fixes in einer Zeile zusammen, die mit Behoben beginnt. Streich Dankeszeilen und jede Bitte um eine Bewertung oder ums Teilen, die Google ohnehin nicht in Release Notes sehen will. Entferne Änderungen, die nur auf dem iPhone oder der Apple Watch angekommen sind. Füg das Ergebnis dann im Tab Google Play unseres Zeichenzählers für den App Store in das Feld für Release Notes ein und sieh die Zahl, bevor die Play Console sie dir zeigt.
Die Formatierung ist schlicht. Googles Hilfeseite spricht von Textzeilen und Sprachtags und sagt nichts über Fettdruck, Links oder Aufzählungszeichen. Schreib also so, als würde nichts davon angezeigt. Eine Änderung pro Zeile liest sich auf dem Smartphone gut, und ein Wort wie Neu oder Behoben am Zeilenanfang erledigt die Arbeit eines Aufzählungszeichens.
Lieferst du über eine Pipeline aus, musst du die Notizen gar nicht in die Play Console tippen. In der Google Play Developer API hat jedes Release in einem Track ein Feld releaseNotes, das die Referenz der API als Beschreibung dessen erklärt, was in diesem Release neu ist, angegeben als lokalisierter Text. Die Action supply von fastlane liest die Notizen aus einem Ordner changelogs pro Sprache. Jede Datei trägt dort den Versionscode, zu dem sie gehört, und eine Datei default.txt springt ein, wenn keine passt. Das Limit von 500 Zeichen gilt trotzdem für alles, was das Skript schickt.
Release Notes weiterverwenden: Social Post, Changelog und mehr
Den schwierigsten Teil hast du schon erledigt, nämlich zu entscheiden, was in dieser Version zählt. Dieselben paar Zeilen taugen für vier weitere Orte.
Ein Social Post
Nimm die zwei oder drei Punkte, die auch Fremde interessieren, fang mit dem Nutzen an und häng einen echten Screenshot der Funktion an. Lass Fixes weg, außer der Fehler war berühmt. Ausgearbeitete Beispiele für jedes Netzwerk findest du in unseren Beispielen für Ankündigungen von App Updates, und einen Plan für jeden Kanal in So bewirbst du eine App auf Social Media.
Ein Changelog auf deiner Website
Stell die Notizen jeder Version auf eine Seite, die neueste zuerst, mit dem Datum des Releases. Das sind die Grundlagen, die Keep a Changelog empfiehlt: ein Eintrag für jede Version, die neueste oben und das Datum dabei. Anders als im Store bleibt auf deiner eigenen Seite die ganze Geschichte an einem Ort lesbar.
Ein Bildschirm mit Neuigkeiten in der App
Updates aus dem App Store installieren sich standardmäßig automatisch. Der erste Start nach einem Update ist also der eine Moment, in dem du sicher sein kannst, dass Nutzer die Neuigkeit sehen. Zeig die ein oder zwei wichtigsten Punkte einmal an, mit einer Taste zum Ausprobieren der Funktion, und sperr die App nie dahinter.
Werbetext und Screenshots im Store
Mach aus dem wichtigsten Punkt eine Zeile mit höchstens 170 Zeichen für den Werbetext im App Store, den du ohne neue Version ändern kannst. Hat sich mit dem Release das Aussehen der App geändert, aktualisiere die Screenshots in derselben Einreichung. Die Maße stehen in unserer Übersicht der Größen für Screenshots im App Store.
Bei schrittweiser Veröffentlichung vorsichtig formulieren
Veröffentlichst du im App Store schrittweise (Phased Release), erreichen die automatischen Updates die Leute über 7 Tage, beginnend mit 1 % am ersten Tag, wie Apples Seite zur schrittweisen Veröffentlichung beschreibt. Jeder kann trotzdem jederzeit von Hand im App Store aktualisieren. Ein Post mit „ab sofort verfügbar“ stimmt also, „alle haben es schon“ dagegen nicht.
Ein Fix ist immer eine neue Version
Apple stellt klar, dass du im App Store nicht zu einer früheren Version zurückkehren kannst. Geht ein Release schief, legst du eine neue Version an, und die bekommt eigene Notizen. Schreib sie wie das Beispiel zur Entschuldigung oben und trag die Lehre daraus in deine App Launch Checkliste ein.
Aus den Release Notes jeder Version einen Post machen, mit Spreadcast
Gute Notizen schreiben und dann niemandem davon erzählen, so läuft es meistens. Das Release geht raus, der Store aktualisiert sich still, und die Social Media Kanäle bleiben stumm, weil der Post noch eine Aufgabe mehr wäre.
Diesen Schritt übernimmt Spreadcast. Du fügst deinen App Store Link auf der Einstiegsseite ein, und Spreadcast prüft den öffentlichen Eintrag jeden Tag. Erscheint eine neue Version, fasst es die Release Notes in zwei oder drei Punkten zusammen, setzt sie auf ein gestaltetes Bild mit einem Screenshot deiner eigenen App und veröffentlicht den Post in den Netzwerken, die du verbunden hast, oder wartet vorher auf deine Freigabe mit einem Tippen. Das funktioniert heute mit Einträgen im App Store, Google Play wird noch nicht unterstützt. Spreadcast selbst ist auf Englisch.
Je besser deine Notizen, desto besser der Post. Ein Grund mehr, mit „Fehlerbehebungen und Leistungsverbesserungen“ aufzuhören. Den Rest des Plans findest du in So vermarktest du eine App und in unserer Erklärung der Richtlinien für das App Store Marketing.
Häufige Fragen
Was sind Release Notes bei einer App?
Release Notes sind eine kurze Beschreibung dessen, was sich in einer neuen Version einer App geändert hat: neue Funktionen, Verbesserungen und behobene Fehler. Im deutschen App Store erscheinen sie unter „Neue Funktionen“, in App Store Connect heißt das Feld What's New in this Version, und in der englischen Play Console ist es mit „What's new in this release?“ beschriftet. Sie sind für Nutzer geschrieben und beschreiben Änderungen deshalb in Alltagssprache.
Wie lang dürfen Release Notes im App Store sein?
4.000 Zeichen. Apples Referenz für das Feld What's New in this Version nennt ein Limit von 4.000 Zeichen, sagt, dass es für die erste Version einer App nicht verfügbar ist, und macht es für alle späteren Versionen zur Pflicht. Siehe Apples Versionsinformationen, geprüft am 4. November 2026.
Wie viele Zeichen haben Release Notes bei Google Play?
500 Unicode Zeichen pro Sprache, laut Play Console Hilfe von Google, zuletzt gelesen am 17. Oktober 2026. Das ist ein Achtel des Limits im App Store. Schreib die Fassung für Google Play deshalb als eigenen, kurzen Text.
Reicht „Fehlerbehebungen und Leistungsverbesserungen“?
Nur wenn das Release wirklich nichts anderes enthält. Apples Richtlinie 2.3.12 erlaubt eine allgemeine Beschreibung für einfache Bugfixes, Sicherheitsupdates und Verbesserungen der Leistung und verlangt, dass größere Änderungen aufgeführt werden. Selbst wenn es erlaubt ist, hilft der Name des behobenen Fehlers der Person, die ihn gemeldet hat, mehr.
Brauche ich Release Notes für die erste Version einer neuen App?
Im App Store nicht. Laut Apple ist das Feld What's New für die erste Version einer App nicht verfügbar, also tragen Beschreibung und Werbetext den Launch. Schreibst du für ein erstes Release bei Google Play eine Notiz, beschreib, was die App tut und wie man Feedback schickt, wie im Beispiel zum ersten Release oben.
Kann ich Release Notes im App Store ändern, wenn das Update live ist?
Plan so, als ginge es nicht. Apples Liste der Eigenschaften, die du ohne neue Version bearbeiten kannst, enthält What's New nicht. Der Werbetext ist das Feld, das du jederzeit ändern kannst. Nutze ihn für Korrekturen oder Neuigkeiten zwischen zwei Versionen. Die Liste steht in Apples Übersicht der Pflichtfelder sowie der lokalisierbaren und bearbeitbaren Eigenschaften.
Wie lang sollten Release Notes sein?
Lang genug, um jede Änderung zu nennen, die ein Nutzer bemerken kann, und nicht länger. Bei den meisten Updates sind das zwei bis sechs kurze Zeilen, und die passen auch in die 500 Zeichen von Google Play. Eine große Version darf mehr von den 4.000 Zeichen des App Store nutzen, mit der größten Änderung zuerst.
Wie sieht ein gutes Beispiel für Release Notes einer Android App aus?
Fast jedes Beispiel auf dieser Seite funktioniert auch für Android, denn jedes bleibt unter dem Limit von 500 Zeichen bei Google Play (das zu TestFlight ist für Apples Betatool gedacht). Ein typisches: „Neu: gemeinsame Budgets, lade eine Person ein, und ihr seht beide jede Ausgabe, sobald sie eingetragen ist. Verbessert: Die Suche schaut auch in Notizen. Behoben: doppelte Bankimporte.“ Bleib bei Information, denn Google will in Release Notes keine Werbung und keine Aufforderungen an Nutzer.
Kann ich Release Notes ändern, während die App geprüft wird?
Ja, aber nur über einen Umweg. Nimm die Version aus der Prüfung, dann steht sie auf Developer Rejected. Ändere die Notizen und reiche neu ein. Laut Apple beginnt die Prüfung nach dem erneuten Einreichen von vorn. Die Schritte stehen auf Apples Seite zum Zurückziehen einer Einreichung aus der Prüfung.
Was gehört in Release Notes?
Jede Änderung in dieser Version, die ein Nutzer bemerken kann, die größte zuerst: neue Funktionen und wo man sie findet, alles, was umgezogen ist oder entfernt wurde, und Fehler, benannt nach dem, was man gesehen hat. Sag dazu, wer betroffen ist, wenn eine Änderung nur manche Leute trifft, etwa Abonnenten oder ein bestimmtes Gerät. Lass interne Arbeit, Ticketnummern und Preise in einer einzigen Währung weg.
Woher diese Angaben stammen
Jede externe Zahl, Regel und jeder Preis auf dieser Seite verlinkt die Seite, von der er stammt.
- Versionsinformationen, darunter das Feld What's New (auf Englisch)Apple Developer, App Store Connect Help
- Pflichtfelder sowie lokalisierbare und bearbeitbare Eigenschaften (auf Englisch)Apple Developer, App Store Connect Help
- App Informationen lokalisieren (auf Englisch)Apple Developer, App Store Connect Help
- Eine neue Version anlegen (auf Englisch)Apple Developer, App Store Connect Help
- Ein Versionsupdate schrittweise veröffentlichen (auf Englisch)Apple Developer, App Store Connect Help
- Die Produktseite gestalten, darunter What's New und Werbetext (auf Englisch)Apple Developer
- App Review Guidelines, Richtlinie 2.3.12 (auf Englisch)Apple Developer
- Apps manuell im App Store aktualisierenApple Support
- Pages im deutschen App Store: Neue Funktionen und VersionsverlaufApple, App Store
- Release vorbereiten und einführenPlay Console Hilfe
- Keep a Changelog, Version 1.1.0Keep a Changelog
- Überblick zu TestFlight: Testinformationen und Feedback von Testern (auf Englisch)Apple Developer, App Store Connect Help
- Eine Einreichung aus der Prüfung zurückziehen (auf Englisch)Apple Developer, App Store Connect Help
- Lokalisierung einer App Store Version ändern, mit whatsNew (auf Englisch)Apple Developer, App Store Connect API
- deliver: Metadaten und Release Notes in den App Store hochladen (auf Englisch)fastlane docs
- supply: Metadaten und Changelogs zu Google Play hochladen (auf Englisch)fastlane docs
- Google Play Developer API: edits.tracks und Release Notes (auf Englisch)Google for Developers
- Video: eine neue Version in App Store Connect veröffentlichen (auf Englisch)Think Like an Engineer
Recherchiert und geschrieben von Spreadcast. Zuletzt geprüft am 4. November 2026.