Voorbeelden van App Store release notes: schrijf een What's New-tekst die zegt wat er veranderd is (2026)

Goede App Store release notes beantwoorden één vraag: wat is er voor mij anders na de update? De voorbeelden van App Store release notes hieronder volgen allemaal één patroon. Begin met de wijziging die de gebruiker zal opmerken, benoem elke fix concreet en laat weg wat niet zichtbaar is. Apples eigen richtlijnen voor het veld What's New in This Version zeggen hetzelfde. Ze vragen om nieuwe functies, UI-verbeteringen of bugfixes en raden aan gebruikers "the specifics of the changes, improvements, or fixes in the version" te vertellen.

Wat zijn de regels voor release notes in App Store Connect en Google Play?

Apples What's New-veld biedt ruimte voor 4.000 tekens en is verplicht bij elke versie na de eerste. Google Play staat 500 Unicode-tekens per taal toe en verbiedt promotionele inhoud.

Per oktober 2026 zegt Play Console Help: "Do not use release notes for promotional purposes or to solicit user actions." Zet bij Apple marketingteksten in plaats daarvan in Promotional Text. Dat veld biedt 170 tekens, verschijnt boven je beschrijving en Apple laat je het bijwerken zonder een nieuwe versie in te dienen.

Hoe zien goede App Store release notes eruit?

Goede release notes benoemen de situatie waarin de gebruiker zat en het resultaat dat die nu krijgt. De voorbeelden hieronder komen van een fictieve habit-tracking-app. De vage versies zijn het soort notities dat op het laatste moment wordt geschreven.

Is een fix te technisch om in één zin uit te leggen, dan merken gebruikers hem waarschijnlijk niet op en kan hij onder één regel "stabiliteitsverbeteringen" aan het einde. Richtlijn 2.3.12 staat dat toe voor kleine fixes, maar niet voor echte functiewijzigingen.

Is er een sjabloon voor release notes dat ik kan hergebruiken?

Ja. Een herbruikbaar sjabloon heeft een kopregel en daarna de secties New, Improved en Fixed. Bewaar het in je repository naast de changelog en vul het in wanneer je de release-branch aanmaakt, niet nadat de build is geüpload.

[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.

Kort dezelfde notities voor Google Play in tot de kopregel plus de belangrijkste twee of drie bullets, zodat ze binnen 500 tekens passen. Zet de tags van elke taal op aparte regels, bijvoorbeeld <en-US> en </en-US>. Laat de slotregel op Play weg, omdat die de gebruiker vraagt iets te doen.

Hoe maak je van gemergde pull requests release notes?

Om gemergde pull requests om te zetten in release notes filter je eerst wijzigingen weg die gebruikers niet zien, en herschrijf je elke resterende wijziging als symptoom of resultaat. Volg deze stappen bij elke release.

1. Exporteer de titels van gemergde pull requests sinds de laatste tag en verwijder alles wat gebruikers niet zien, zoals refactors, dependency-updates en CI-wijzigingen.
2. Herschrijf elk resterend item als symptoom of resultaat. "Fix nil coordinator" wordt "Leeg scherm verholpen na inloggen met Apple."
3. Orden de items op hoeveel gebruikers ze raken, niet op hoeveel engineeringwerk ze kostten.
4. Maak in App Store Connect de nieuwe versie aan en wis de gekopieerde What's New-tekst voordat je de nieuwe notities plakt, omdat de metadata van de vorige versie wordt overgenomen.
5. Plak de notities in elke lokalisatie die je ondersteunt, vertaald of op zijn minst per taal gecontroleerd, zodat gebruikers in andere landinstellingen niet de notities van de vorige versie zien.
6. Plak voor Play de ingekorte versie binnen de taaltags en controleer dat elke taal onder de 500 tekens blijft.
7. Lees de notities één keer hardop voor. Heeft een zin een developer nodig om hem uit te leggen, herschrijf hem dan.

Wat moeten release notes zeggen bij een hotfix?

Release notes voor een hotfix noemen de kapotte versie, beschrijven het symptoom dat nu is verholpen en vertellen getroffen gebruikers wat er gebeurt na de update. Apple laat je niet terugkeren naar een eerdere versie in de App Store, dus een fix wordt altijd als nieuwe versie uitgebracht.

Een voorbeeld: "Probleem in 3.4.0 verholpen waardoor herinneringen bij sommige gebruikers niet meer afgingen. Herinneringen die je vóór de update had ingesteld, werken automatisch weer." Getroffen gebruikers weten dat ze moeten updaten, en wie niet getroffen was, ziet dat de fix niet voor hen geldt. Geef het besturingssysteem niet de schuld en beloof geen data voor toekomstige fixes. Breng je updates uit met een gefaseerde release, dan beperkt het pauzeren van de uitrol hoeveel gebruikers de kapotte build krijgen terwijl de fix in review is. Verandert de hotfix hoe een functie werkt, loop dan de App Store-checklist voor indienen opnieuw door, zodat notities, screenshots en review-notities overeenkomen.

Kan App Review een update afwijzen vanwege de release notes?

Ja. Release notes zijn metadata en de App Review Guidelines behandelen ze rechtstreeks. Richtlijn 2.3.12 zegt: "Apps must clearly describe new features and product changes in their "What's New" text."

Algemene bewoordingen zijn toegestaan voor "simple bug fixes, security updates, and performance improvements", maar "more significant changes must be listed in the notes." Richtlijn 2.3.10 verbiedt namen of afbeeldingen van andere mobiele platforms in metadata, en daar valt What's New ook onder. Beschrijf geen functies die achter flags verborgen zitten of iets wat niet in de ingediende build zit. Richtlijn 2.3.1(a) vereist daarnaast dat nieuwe functies "described with specificity in the Notes for Review section" worden, dus zet stappen voor de reviewer en een demo-account daar, niet in de openbare notities. Krijg je toch een vraag over metadata, dan legt onze gids over App Store-afwijzingen oplossen uit hoe je reageert.

Welke problemen met release notes hebben andere developers gehad?

Openbaar gemelde gevallen laten twee soorten fouten zien: uploads die worden geweigerd omdat ze de lengtelimiet van een store overschrijden, en review-afwijzingen waarbij What's New-tekst in de opschooninstructies wordt genoemd.

• Play-lengtelimiet in CI. Een GitHub-issue in een Flutter-deploymenttemplate meldt een door AI gegenereerde changelog die een interne testupload naar Google Play via fastlane liet mislukken met: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." De maintainers voegden een script toe dat notities vóór de upload inkort: 480 tekens voor Play en 3.800 bytes voor TestFlight, dat zijn limiet in bytes meet.
• 2.3.10-opschoning inclusief What's New. Een developer op de Apple Developer Forums deelde een afwijzing onder richtlijn 2.3.10, veroorzaakt door niet-iOS-statusbalken in screenshots. Apples vervolgstappen luidden: "remove all instances of this information from your app and its metadata, including the app description, promotional text, What's New info, previews, and screenshots." Reacties adviseerden screenshots opnieuw te maken en elk metadataveld te controleren, release notes inbegrepen.

De les: de lengtelimiet is mechanisch en faalt luid bij het uploaden, terwijl reviewregels over inhoud gaan en voor elk metadataveld gelden. Automatiseer een tekencontrole en lees What's New met dezelfde zorg als je screenshots.

Wat moet je controleren voordat je release notes indient?

Controleer vóór het indienen dat de notities alleen beschrijven wat in de build zit, binnen de limieten van elke store passen en in elke taal de tekst van de vorige versie vervangen.

• De kopregel noemt de wijziging die de meeste gebruikers zullen opmerken.
• Elke belangrijke functie of productwijziging staat vermeld, zoals richtlijn 2.3.12 vereist.
• Elke fix beschrijft een symptoom dat de gebruiker zag, geen interne code.
• Geen functies achter flags, geen beloftes voor de toekomst, geen interne ticketnummers, geen namen van andere platforms.
• De What's New-tekst van de vorige versie is in elke lokalisatie gewist en vervangen.
• Play-notities blijven onder de 500 tekens per taal, staan tussen correcte taaltags en bevatten geen promotie of oproepen tot actie.
• Marketingboodschappen zijn bij Apple verplaatst naar Promotional Text.
• Werk je ook met Android-testers, dan zijn dezelfde notities getoetst aan je plan voor gesloten tests.

Wil je dat iemand anders je update-metadata nakijkt voordat je indient, mail dan yagyeshsrbobde@gmail.com met je conceptnotities en de lijst met wijzigingen in de build, of bekijk onze diensten.