Exempel på versionsanteckningar för App Store: skriv What's New-text som berättar vad som har ändrats (2026)

Bra versionsanteckningar för App Store besvarar en fråga: vad är annorlunda för mig efter att jag har uppdaterat? Exemplen på versionsanteckningar nedan följer alla samma mönster. Börja med ändringen användaren kommer att märka, namnge varje rättning konkret och utelämna allt de inte kan se. Apples egen vägledning för fältet What's New in This Version säger samma sak. Den efterfrågar nya funktioner, förbättringar av gränssnittet eller buggrättningar och rekommenderar att du berättar för användarna om "detaljerna i ändringarna, förbättringarna eller rättningarna i versionen".

Vilka regler gäller för versionsanteckningar i App Store Connect och Google Play?

Apples What's New-fält rymmer 4 000 tecken och krävs för varje version efter den första. Google Play tillåter 500 Unicode-tecken per språk och förbjuder reklaminnehåll.

I oktober 2026 säger Play Console-hjälpen: "Använd inte versionsanteckningar i reklamsyfte eller för att uppmana användare till handlingar." Hos Apple lägger du i stället marknadsföringstext i Promotional Text. Det fältet rymmer 170 tecken, visas ovanför din beskrivning och Apple låter dig uppdatera det utan att skicka in en ny version.

Hur ser bra versionsanteckningar för App Store ut?

Bra versionsanteckningar beskriver situationen användaren befann sig i och resultatet de nu får. Exemplen nedan kommer från en fiktiv app för vanespårning. De vaga versionerna är den sortens anteckningar som skrivs i sista minuten.

Om en rättning är för teknisk för att förklaras i en mening kommer användarna förmodligen inte att märka den, så den kan hamna under en enda rad om "stabilitetsförbättringar" i slutet. Riktlinje 2.3.12 tillåter det för mindre rättningar men inte för verkliga funktionsändringar.

Finns det en mall för versionsanteckningar som jag kan återanvända?

Ja. En återanvändbar mall har en rubrik följd av sektionerna Nytt, Förbättrat och Rättat. Förvara den i ditt repository bredvid ändringsloggen och fyll i den när du skapar releasegrenen, inte efter att bygget har laddats upp.

[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 kortar du ner samma anteckningar till rubriken plus de två eller tre viktigaste punkterna så att de ryms inom 500 tecken. Placera varje språks taggar på egna rader, till exempel <en-US> och </en-US>. Stryk avslutningsraden på Play, eftersom den uppmanar användaren att göra något.

Hur gör man versionsanteckningar av sammanslagna pull requests?

För att göra versionsanteckningar av sammanslagna pull requests filtrerar du bort ändringar som användarna inte kan se och skriver sedan om varje återstående ändring som ett symtom eller ett resultat. Följ de här stegen inför varje release.

1. Exportera titlarna på de pull requests som slagits samman sedan den senaste taggen och ta sedan bort allt användarna inte kan se, till exempel refaktoreringar, beroendeuppdateringar och CI-ändringar.
2. Skriv om varje återstående punkt som ett symtom eller ett resultat. "Fix nil coordinator" blir "Rättat en tom skärm efter inloggning med Apple."
3. Ordna punkterna efter hur många användare de påverkar, inte efter hur mycket utvecklingsarbete de krävde.
4. Skapa den nya versionen i App Store Connect och rensa den kopierade What's New-texten innan du klistrar in de nya anteckningarna, eftersom föregående versions metadata följer med.
5. Klistra in anteckningarna i varje lokalisering du stöder, översatta eller åtminstone kontrollerade på varje språk, så att användare i andra språkområden inte ser förra versionens anteckningar.
6. För Play klistrar du in den förkortade versionen inom språktaggarna och kontrollerar att varje språk håller sig under 500 tecken.
7. Läs anteckningarna högt en gång. Om en mening kräver en utvecklare för att förklaras, skriv om den.

Vad ska versionsanteckningarna säga för en snabbrättning?

Versionsanteckningar för en snabbrättning (hotfix) ska namnge den trasiga versionen, beskriva symtomet som nu är rättat och berätta för berörda användare vad som händer efter att de uppdaterat. Apple låter dig inte återgå till en tidigare version på App Store, så en rättning levereras alltid som en ny version.

Ett exempel: "Rättat ett problem i 3.4.0 där påminnelser slutade fungera för vissa användare. Påminnelser du ställde in före uppdateringen återupptas automatiskt." Användare som drabbades vet att de ska uppdatera, och användare som inte drabbades kan se att rättningen inte berör dem. Skyll inte på operativsystemet och lova inga datum för framtida rättningar. Om du levererar uppdateringar med en stegvis lansering begränsar en paus i utrullningen hur många användare som får det trasiga bygget medan rättningen granskas. Om snabbrättningen ändrar hur en funktion beter sig, gå igenom checklistan för inskickning till App Store igen så att anteckningar, skärmbilder och granskningsanteckningar stämmer överens.

Kan App Review avslå en uppdatering på grund av dess versionsanteckningar?

Ja. Versionsanteckningar är metadata, och App Review Guidelines täcker dem direkt. Riktlinje 2.3.12 säger att "appar måste tydligt beskriva nya funktioner och produktändringar i sin What's New-text".

Generiska formuleringar är tillåtna för "enkla buggrättningar, säkerhetsuppdateringar och prestandaförbättringar", men "mer betydande ändringar måste listas i anteckningarna". Riktlinje 2.3.10 förbjuder namn eller bilder från andra mobilplattformar i metadata, vilket inkluderar What's New. Beskriv inte funktioner som döljs bakom flaggor eller något som inte finns i det inskickade bygget. Riktlinje 2.3.1(a) kräver dessutom att nya funktioner "beskrivs konkret i avsnittet Notes for Review", så lägg instruktioner till granskaren och ett demokonto där, inte i de offentliga anteckningarna. Om du ändå får en fråga om metadata förklarar vår guide om att åtgärda avslag i App Store hur du svarar.

Vilka problem med versionsanteckningar har andra utvecklare stött på?

Offentligt rapporterade fall visar två typer av fel: uppladdningar som avvisas för att de överskrider en butiks längdgräns, och avslag i granskningen där What's New-texten ingår i instruktionerna om vad som ska rensas.

• Plays längdgräns i CI. Ett GitHub-ärende i en mall för Flutter-driftsättning rapporterar en AI-genererad ändringslogg som fick en uppladdning till Google Plays interna test via fastlane att misslyckas med: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." Underhållarna lade till ett skript som kortar anteckningarna före uppladdning: 480 tecken för Play och 3 800 byte för TestFlight, som mäter sin gräns i byte.
• Rensning enligt 2.3.10 som inkluderar What's New. En utvecklare på Apple Developer Forums publicerade ett avslag enligt riktlinje 2.3.10 som utlösts av statusfält från andra system än iOS i skärmbilderna. Apples nästa steg sade att man skulle "ta bort alla förekomster av denna information från din app och dess metadata, inklusive appbeskrivningen, reklamtexten, What's New-informationen, förhandsvisningar och skärmbilder". Svaren rådde att ta om skärmbilderna och kontrollera varje metadatafält, versionsanteckningarna inräknade.

Slutsatsen: längdgränsen är mekanisk och misslyckas tydligt vid uppladdningen, medan granskningsreglerna handlar om innehåll och gäller varje metadatafält. Automatisera en teckenkontroll och läs What's New med samma noggrannhet som dina skärmbilder.

Vad ska du kontrollera innan du skickar in versionsanteckningar?

Kontrollera innan inskickning att anteckningarna bara beskriver det som finns i bygget, håller sig inom varje butiks gränser och ersätter förra versionens text på alla språk.

• Rubriken namnger den ändring de flesta användare kommer att märka.
• Varje betydande funktion eller produktändring är listad, som riktlinje 2.3.12 kräver.
• Varje rättning beskriver ett symtom användaren såg, inte intern kod.
• Inga funktioner bakom flaggor, inga löften om framtiden, inga interna ärendenummer, inga namn på andra plattformar.
• Föregående versions What's New-text är rensad och ersatt i varje lokalisering.
• Play-anteckningarna är under 500 tecken per språk, omslutna av korrekta språktaggar, utan reklam eller uppmaningar till handling.
• Marknadsföringsbudskap är flyttade till Promotional Text hos Apple.
• Om du också har Android-testare har samma anteckningar kontrollerats mot din plan för sluten testning.

Om du vill att någon annan går igenom metadatan för din uppdatering innan du skickar in den, mejla yagyeshsrbobde@gmail.com med ditt utkast till anteckningar och listan över ändringar i bygget, eller se våra tjänster.