Esempi di note di rilascio App Store: scrivi un testo Novità che dica agli utenti cosa è cambiato (2026)

Delle buone note di rilascio App Store rispondono a una sola domanda: cosa cambia per me dopo l'aggiornamento? Gli esempi di note di rilascio App Store qui sotto seguono tutti lo stesso schema. Apri con la modifica che l'utente noterà, indica ogni correzione in modo specifico e tralascia tutto ciò che non può vedere. La guida di Apple per il campo What's New in This Version dice la stessa cosa: chiede nuove funzionalità, miglioramenti dell'interfaccia o correzioni di bug e raccomanda di comunicare agli utenti "i dettagli delle modifiche, dei miglioramenti o delle correzioni nella versione".

Quali sono le regole per le note di rilascio in App Store Connect e Google Play?

Il campo What's New di Apple consente 4.000 caratteri ed è obbligatorio per ogni versione successiva alla prima. Google Play consente 500 caratteri Unicode per lingua e vieta i contenuti promozionali.

A ottobre 2026, la guida di Play Console afferma: "Non utilizzare le note di rilascio per scopi promozionali o per sollecitare azioni degli utenti." Su Apple, inserisci invece i testi di marketing nel Promotional Text. Quel campo consente 170 caratteri, compare sopra la descrizione e Apple permette di aggiornarlo senza inviare una nuova versione.

Come sono fatte delle buone note di rilascio App Store?

Le buone note di rilascio descrivono la situazione in cui si trovava l'utente e il risultato che ottiene ora. Gli esempi seguenti riguardano un'app immaginaria per il monitoraggio delle abitudini. Le versioni vaghe sono il tipo di note scritte all'ultimo minuto.

Se una correzione è troppo tecnica per essere spiegata in una frase, probabilmente gli utenti non la noteranno, quindi può finire sotto un'unica riga "miglioramenti della stabilità" in fondo. La linea guida 2.3.12 lo consente per le correzioni minori, ma non per vere modifiche alle funzionalità.

Esiste un modello di note di rilascio riutilizzabile?

Sì. Un modello riutilizzabile ha un titolo, poi le sezioni Nuovo, Migliorato e Corretto. Tienilo nel repository accanto al changelog e compilalo quando crei il branch di release, non dopo il caricamento della build.

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

Per Google Play, riduci le stesse note al titolo più i due o tre punti principali, così da rientrare nei 500 caratteri. Metti i tag di ogni lingua su righe a sé, per esempio <en-US> e </en-US>. Elimina la riga di chiusura su Play, perché chiede all'utente di fare qualcosa.

Come trasformare le pull request unite in note di rilascio?

Per trasformare le pull request unite in note di rilascio, scarta le modifiche che gli utenti non vedono, poi riscrivi ogni modifica rimanente come sintomo o risultato. Segui questi passaggi per ogni release.

1. Esporta i titoli delle pull request unite dall'ultimo tag, poi elimina tutto ciò che gli utenti non vedono, come refactoring, aggiornamenti delle dipendenze e modifiche alla CI.
2. Riscrivi ogni voce rimanente come sintomo o risultato. "Fix nil coordinator" diventa "Risolta una schermata vuota dopo l'accesso con Apple."
3. Ordina le voci in base a quanti utenti coinvolgono, non a quanto lavoro di sviluppo hanno richiesto.
4. In App Store Connect, crea la nuova versione, poi cancella il testo What's New copiato prima di incollare le nuove note, perché i metadati della versione precedente vengono riportati.
5. Incolla le note in ogni localizzazione che supporti, tradotte o almeno verificate in ciascuna lingua, così gli utenti di altre lingue non vedranno le note dell'ultima versione.
6. Per Play, incolla la versione ridotta dentro i tag di lingua e verifica che ogni lingua resti sotto i 500 caratteri.
7. Leggi le note ad alta voce una volta. Se una frase ha bisogno di uno sviluppatore per essere spiegata, riscrivila.

Cosa dovrebbero dire le note di rilascio di un hotfix?

Le note di rilascio di un hotfix dovrebbero indicare la versione difettosa, descrivere il sintomo ora risolto e spiegare agli utenti coinvolti cosa succede dopo l'aggiornamento. Apple non consente di tornare a una versione precedente sull'App Store, quindi una correzione viene sempre pubblicata come nuova versione.

Un esempio: "Risolto un problema della 3.4.0 per cui i promemoria smettevano di attivarsi per alcuni utenti. I promemoria impostati prima dell'aggiornamento riprenderanno automaticamente." Gli utenti coinvolti sanno di dover aggiornare e quelli non coinvolti capiscono che la correzione non li riguarda. Non dare la colpa al sistema operativo e non promettere date per correzioni future. Se pubblichi gli aggiornamenti con un rilascio graduale, mettere in pausa la distribuzione limita quanti utenti ricevono la build difettosa mentre la correzione è in revisione. Se l'hotfix cambia il comportamento di una funzionalità, ripercorri la checklist per l'invio all'App Store in modo che note, screenshot e note per la revisione siano coerenti.

App Review può rifiutare un aggiornamento a causa delle note di rilascio?

Sì. Le note di rilascio sono metadati e le App Review Guidelines le trattano direttamente. La linea guida 2.3.12 afferma che "le app devono descrivere chiaramente nuove funzionalità e modifiche al prodotto nel testo "What's New"."

Una formulazione generica è consentita per "semplici correzioni di bug, aggiornamenti di sicurezza e miglioramenti delle prestazioni", ma "le modifiche più significative devono essere elencate nelle note". La linea guida 2.3.10 vieta nomi o immagini di altre piattaforme mobili nei metadati, il che include What's New. Non descrivere funzionalità nascoste dietro flag né nulla che non sia nella build inviata. La linea guida 2.3.1(a) richiede inoltre che le nuove funzionalità siano "descritte in modo specifico nella sezione Notes for Review", quindi inserisci lì i passaggi per il revisore e un account demo, non nelle note pubbliche. Se ricevi una domanda sui metadati, la nostra guida alla risoluzione dei rifiuti App Store spiega come rispondere.

Quali problemi con le note di rilascio hanno incontrato altri sviluppatori?

I casi segnalati pubblicamente mostrano due tipi di errore: caricamenti rifiutati per aver superato il limite di lunghezza di uno store e rifiuti in revisione che includono il testo What's New nelle istruzioni di correzione.

• Limite di lunghezza di Play nella CI. Una issue GitHub in un template di deploy Flutter segnala un changelog generato dall'IA che ha fatto fallire un caricamento per il test interno su Google Play tramite fastlane con: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." I maintainer hanno aggiunto uno script che tronca le note prima del caricamento: 480 caratteri per Play e 3.800 byte per TestFlight, che misura il suo limite in byte.
• Correzione per la 2.3.10 che include What's New. Uno sviluppatore sugli Apple Developer Forums ha pubblicato un rifiuto per la linea guida 2.3.10 causato da barre di stato non iOS negli screenshot. I passaggi successivi indicati da Apple chiedevano di "rimuovere ogni occorrenza di queste informazioni dall'app e dai suoi metadati, inclusi descrizione dell'app, testo promozionale, informazioni What's New, anteprime e screenshot". Le risposte consigliavano di rifare gli screenshot e di controllare ogni campo dei metadati, note di rilascio comprese.

La lezione: il limite di lunghezza è meccanico e fallisce in modo evidente al caricamento, mentre le regole della revisione riguardano il contenuto e si applicano a ogni campo dei metadati. Automatizza un controllo dei caratteri e rileggi What's New con la stessa cura degli screenshot.

Cosa controllare prima di inviare le note di rilascio?

Prima dell'invio, verifica che le note descrivano solo ciò che è nella build, rispettino i limiti di ogni store e sostituiscano il testo dell'ultima versione in ogni lingua.

• Il titolo indica la modifica che la maggior parte degli utenti noterà.
• Ogni funzionalità o modifica al prodotto significativa è elencata, come richiede la linea guida 2.3.12.
• Ogni correzione descrive un sintomo visto dall'utente, non codice interno.
• Nessuna funzionalità dietro flag, nessuna promessa futura, nessun numero di ticket interno, nessun nome di altre piattaforme.
• Testo What's New della versione precedente cancellato e sostituito in ogni localizzazione.
• Note per Play sotto i 500 caratteri per lingua, racchiuse nei tag di lingua corretti, senza promozioni né inviti all'azione.
• Messaggi di marketing spostati nel Promotional Text su Apple.
• Se hai anche tester Android, le stesse note sono state verificate rispetto al tuo piano di test chiuso.

Se vuoi un secondo parere sui metadati del tuo aggiornamento prima dell'invio, scrivi a yagyeshsrbobde@gmail.com con la bozza delle note e l'elenco delle modifiche nella build, oppure consulta i nostri servizi.