Exemplos de notas de versão da App Store: escreva um texto de Novidades que mostre o que mudou (2026)

Boas notas de versão da App Store respondem a uma pergunta: o que muda para mim depois que eu atualizo? Os exemplos de notas de versão da App Store abaixo seguem todos o mesmo padrão. Comece pela mudança que o usuário vai perceber, cite cada correção de forma específica e deixe de fora o que ele não consegue ver. A própria orientação da Apple para o campo What's New in This Version diz o mesmo. Ela pede novos recursos, melhorias de interface ou correções de bugs e recomenda informar aos usuários "os detalhes das mudanças, melhorias ou correções da versão".

Quais são as regras de notas de versão no App Store Connect e no Google Play?

O campo What's New da Apple aceita 4.000 caracteres e é obrigatório em todas as versões depois da primeira. O Google Play aceita 500 caracteres Unicode por idioma e proíbe conteúdo promocional.

Em outubro de 2026, a Ajuda do Play Console diz: "Não use as notas de versão para fins promocionais nem para pedir ações aos usuários." Na Apple, coloque textos de marketing em Promotional Text. Esse campo aceita 170 caracteres, aparece acima da descrição e a Apple permite atualizá-lo sem enviar uma nova versão.

Como são boas notas de versão da App Store?

Boas notas de versão descrevem a situação em que o usuário estava e o resultado que ele passa a ter. Os exemplos abaixo vêm de um app fictício de acompanhamento de hábitos. As versões vagas são o tipo de nota escrita no último minuto.

Se uma correção é técnica demais para ser explicada em uma frase, o usuário provavelmente não vai notá-la, então ela pode entrar em uma única linha de "melhorias de estabilidade" no fim. A diretriz 2.3.12 permite isso para correções pequenas, mas não para mudanças reais de recursos.

Existe um modelo de notas de versão que eu possa reutilizar?

Sim. Um modelo reutilizável tem um título e depois as seções Novo, Melhorado e Corrigido. Guarde-o no repositório ao lado do changelog e preencha-o quando criar a branch de release, não depois que o build já foi enviado.

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

Para o Google Play, reduza as mesmas notas ao título mais os dois ou três principais tópicos, para caberem em 500 caracteres. Coloque as tags de cada idioma em linhas próprias, por exemplo <en-US> e </en-US>. Remova a linha de encerramento no Play, porque ela pede uma ação ao usuário.

Como transformar pull requests mesclados em notas de versão?

Para transformar pull requests mesclados em notas de versão, filtre as mudanças que o usuário não vê e reescreva cada mudança restante como um sintoma ou um resultado. Siga estes passos em toda versão.

1. Exporte os títulos dos pull requests mesclados desde a última tag e apague tudo o que o usuário não vê, como refatorações, atualizações de dependências e mudanças de CI.
2. Reescreva cada item restante como um sintoma ou um resultado. "Fix nil coordinator" vira "Corrigida uma tela em branco após entrar com a Apple."
3. Ordene os itens pela quantidade de usuários afetados, não pelo esforço de engenharia que exigiram.
4. No App Store Connect, crie a nova versão e apague o texto de What's New copiado antes de colar as novas notas, porque os metadados da versão anterior são herdados.
5. Cole as notas em todas as localizações que você suporta, traduzidas ou pelo menos revisadas em cada idioma, para que usuários de outras regiões não vejam as notas da versão anterior.
6. No Play, cole a versão reduzida dentro das tags de idioma e confirme que cada idioma fica abaixo de 500 caracteres.
7. Leia as notas em voz alta uma vez. Se alguma frase precisa de um desenvolvedor para ser explicada, reescreva-a.

O que as notas de versão devem dizer em um hotfix?

As notas de um hotfix devem citar a versão com problema, descrever o sintoma que foi corrigido e dizer aos usuários afetados o que acontece depois que eles atualizam. A Apple não permite reverter para uma versão anterior na App Store, então uma correção sempre sai como uma nova versão.

Um exemplo: "Corrigido um problema na 3.4.0 em que os lembretes pararam de disparar para alguns usuários. Os lembretes que você configurou antes de atualizar voltam a funcionar automaticamente." Quem foi afetado sabe que precisa atualizar, e quem não foi percebe que a correção não lhe diz respeito. Não culpe o sistema operacional e não prometa datas para correções futuras. Se você publica atualizações com lançamento gradual, pausar o rollout limita quantos usuários recebem o build com problema enquanto a correção está em revisão. Se o hotfix muda o comportamento de um recurso, passe de novo pelo checklist de envio para a App Store para que notas, capturas de tela e notas para a revisão estejam alinhadas.

A App Review pode rejeitar uma atualização por causa das notas de versão?

Sim. Notas de versão são metadados, e as Diretrizes de Revisão da App Store tratam delas diretamente. A diretriz 2.3.12 diz que "os apps devem descrever claramente novos recursos e mudanças no produto no texto de "What's New"."

Texto genérico é permitido para "correções simples de bugs, atualizações de segurança e melhorias de desempenho", mas "mudanças mais significativas devem ser listadas nas notas". A diretriz 2.3.10 proíbe nomes ou imagens de outras plataformas móveis nos metadados, o que inclui o What's New. Não descreva recursos escondidos atrás de flags nem nada que não esteja no build enviado. A diretriz 2.3.1(a) exige, à parte, que novos recursos sejam "descritos de forma específica na seção Notes for Review", então coloque ali os passos para o revisor e uma conta de demonstração, não nas notas públicas. Se você receber uma pergunta sobre metadados, nosso guia de correções de rejeição na App Store explica como responder.

Que problemas com notas de versão outros desenvolvedores já enfrentaram?

Casos relatados publicamente mostram dois tipos de falha: envios rejeitados por passar do limite de tamanho de uma loja e rejeições na revisão que incluem o texto de What's New nas instruções de correção.

• Limite de tamanho do Play no CI. Uma issue no GitHub de um template de deploy Flutter relata um changelog gerado por IA que quebrou um envio para teste interno do Google Play via fastlane com: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." Os mantenedores adicionaram um script que corta as notas antes do envio: 480 caracteres para o Play e 3.800 bytes para o TestFlight, que mede o limite em bytes.
• Correção pela 2.3.10 que inclui o What's New. Um desenvolvedor nos Fóruns de Desenvolvedores da Apple publicou uma rejeição pela diretriz 2.3.10 causada por barras de status que não eram do iOS nas capturas de tela. Os próximos passos da Apple diziam para "remover todas as ocorrências dessas informações do app e de seus metadados, incluindo a descrição do app, o texto promocional, as informações de What's New, as prévias e as capturas de tela". As respostas recomendaram refazer as capturas e revisar todos os campos de metadados, incluindo as notas de versão.

A lição: o limite de tamanho é mecânico e falha de forma evidente no envio, enquanto as regras da revisão tratam do conteúdo e valem para todos os campos de metadados. Automatize uma checagem de caracteres e leia o What's New com o mesmo cuidado que suas capturas de tela.

O que conferir antes de enviar as notas de versão?

Antes de enviar, confira se as notas descrevem apenas o que está no build, cabem nos limites de cada loja e substituem o texto da última versão em todos os idiomas.

• O título cita a mudança que a maioria dos usuários vai perceber.
• Todo recurso ou mudança significativa no produto está listado, como exige a diretriz 2.3.12.
• Cada correção descreve um sintoma que o usuário via, não código interno.
• Nada de recursos atrás de flags, promessas futuras, números de tickets internos ou nomes de outras plataformas.
• O texto de What's New da versão anterior foi apagado e substituído em todas as localizações.
• As notas do Play têm menos de 500 caracteres por idioma, estão nas tags de idioma corretas e não têm promoção nem chamadas para ação.
• As mensagens de marketing foram para o Promotional Text na Apple.
• Se você também tem testadores no Android, as mesmas notas foram conferidas com seu plano de teste fechado.

Se quiser uma segunda opinião sobre os metadados da sua atualização antes de enviar, mande um e-mail para yagyeshsrbobde@gmail.com com o rascunho das notas e a lista de mudanças do build, ou veja nossos serviços.