# Publicar atualização de app iOS: lançamento gradual > Publicar uma atualização iOS: nova versão, novo build, texto de novidades e lançamento manual, automático ou gradual em 7 dias. Página original: [Publicar atualização de app iOS: lançamento gradual](https://devoria.fr/pt-br/blog/publicar-atualizacao-app-ios-lancamento-gradual) Autor: [Mehdi Azizi](https://devoria.fr/pt-br/mehdi-azizi) Publicação: 2026-11-04 Última revisão do conteúdo: 2026-11-04 Para publicar uma atualização iOS, você cria uma nova versão no App Store Connect, com um número maior. Anexa um novo build, escreve o texto de novidades e envia para o App Review. **Toda nova versão passa de novo pela revisão da Apple, mesmo que seja só uma correção.** Antes do envio, você escolhe como ela vai sair depois da aprovação: manualmente, na hora, só a partir de uma data, ou em lançamento gradual ao longo de 7 dias. O lançamento gradual afeta só as atualizações automáticas: 1% desses usuários no primeiro dia, todos no sétimo. Você pode pausar por até 30 dias no total, ou encerrar de uma vez. Este guia segue as páginas de ajuda da Apple, revisadas em 3 de novembro de 2026. Eu publico as atualizações dos meus apps iOS com Expo e EAS, entre eles Solys, TradaZen e Nolera. Os casos citados mais abaixo vêm desses lançamentos. ## Publicar uma atualização iOS: as etapas em ordem [A ajuda do App Store Connect sobre novas versões](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version) descreve este caminho: 1. Em Apps, escolha seu app e clique no botão + ao lado da plataforma. 2. Digite um número de versão maior que o anterior e clique em Create. 3. Revise os metadados: os da versão publicada são copiados automaticamente. 4. Envie um novo build, com o número de build incrementado. 5. Teste esse build no [TestFlight](https://devoria.fr/pt-br/blog/testflight-como-testar-app-iphone-antes-envio), adicione-o à versão e envie para o App Review. Duas condições antes de começar. A versão publicada precisa estar com o status Ready for Distribution. E você precisa de um destes papéis: Account Holder, Admin, App Manager ou Marketing. **Não existe voltar atrás.** A Apple diz isso na mesma página: se uma versão der problema, você não pode voltar para a anterior. Precisa criar e enviar uma nova versão. ## Número de versão e número de build A versão é o número que seus clientes veem na página do app. O build identifica cada envio. **A combinação de versão e build precisa ser única**: as regras e os erros relacionados estão em versão e número de build. Minha convenção, que não é regra da Apple: o último número sobe numa correção, de 1.4.0 para 1.4.1. O do meio sobe numa nova funcionalidade, de 1.4.1 para 1.5.0. Já o número de build só sobe, de uma versão para outra. Com Expo, a versão fica no `app.json` e o EAS pode incrementar o build a cada compilação de produção. A configuração está em [publicar um app Expo com EAS](https://devoria.fr/pt-br/blog/eas-submit-ios-publicar-app-expo-app-store). ## O texto de novidades: o que a Apple exige [A página de informações da versão](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information) descreve o campo What's New in This Version: - **No máximo 4.000 caracteres.** - **Ausente na primeira versão, obrigatório em todas as seguintes.** - **Traduzível em cada idioma da sua página.** A regra 2.3.12 das [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#2.3.12) acrescenta uma exigência: descrever com clareza as novas funcionalidades e as mudanças do produto. Uma frase genérica basta para simples correções de bugs, de segurança ou de desempenho. **Uma mudança importante precisa ser listada.** Então "Correções de bugs e melhorias" não basta para uma versão que muda sua assinatura ou sua tela principal. A Apple também recomenda, na [página dedicada às avaliações](https://developer.apple.com/app-store/ratings-and-reviews/), mencionar nas notas os problemas corrigidos que clientes tinham descrito nas avaliações. Aqui vão três modelos para adaptar, um por tipo de versão. Para uma correção: ```text Correções e estabilidade. - [Funcionalidade]: [o que não funcionava] foi corrigido. - [Tela] carrega mais rápido. Obrigado a quem avisou. ``` Para uma nova funcionalidade: ```text Novo: [a funcionalidade, em cinco palavras]. [O que você pode fazer agora, em uma frase.] Onde encontrar: [aba] > [botão]. Também nesta versão: - [Melhoria visível]. - Correções de bugs. ``` Para um fluxo que muda: ```text [Tela ou fluxo] mudou. - O que muda para você: [efeito concreto]. - O que você mantém: [dados, ajustes, compra]. Alguma dúvida? [Ajustes] > [Ajuda]. ``` A última linha do modelo de correção só vale se alguém realmente relatou o problema. Nunca escreva uma novidade que não está no build: a regra 2.3 exige metadados fiéis ao app. ## Lançamento manual, automático ou numa data [A ajuda sobre as opções de lançamento](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option) oferece três: | Opção | Depois da aprovação da Apple | | --------------------------- | ------------------------------------------------------------ | | Manual | Status Pending Developer Release, você publica quando quiser | | Automático | A versão sai assim que é aprovada | | Automático, não antes de... | Ela espera a data escolhida e depois sai sozinha | No lançamento manual, você abre a versão com status Pending Developer Release, clica em Release This Version e confirma. A Apple avisa que pode levar até 24 horas para ela aparecer na App Store. Uma mensagem na página da versão oferece Cancel This Release para cancelar. Se a versão ficar mais de 30 dias esperando, a Apple manda um lembrete por e-mail. **O lançamento manual serve para escolher o momento**, por exemplo para publicar no dia de um anúncio. O Solys 2.0.0, que trazia uma nova versão da assinatura anual, foi para revisão no fim de setembro de 2026 com lançamento manual. Para uma versão de rotina, deixo o lançamento automático. O Nolera 1.0.2, aprovado em 12 de outubro de 2026, apareceu na App Store menos de um minuto depois do e-mail da Apple, segundo a API pública de busca do iTunes. É uma única observação: conte com folga. ## O lançamento gradual em 7 dias [A ajuda da Apple sobre lançamento gradual](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases) traz o calendário exato: | Dia | Parcela dos usuários | | --- | -------------------- | | 1 | 1% | | 2 | 2% | | 3 | 5% | | 4 | 10% | | 5 | 20% | | 6 | 50% | | 7 | 100% | A atualização vai para uma amostra aleatória dos usuários que ativaram as atualizações automáticas, nos aparelhos compatíveis. Eles não são avisados de que fazem parte dela. **O lançamento gradual só segura as atualizações automáticas.** A Apple deixa claro que qualquer pessoa pode baixar a nova versão na App Store, a qualquer momento. Quem instala seu app, ou toca em "Update" na página dele, pode recebê-la já no primeiro dia. Não é um teste com 1% dos seus usuários: é um freio nos outros. Para ativar, abra a versão, desça até a seção Phased Release for Automatic Updates, marque "Release update over a 7-day period using phased release" e salve. É preciso ter o papel Account Holder, Admin ou App Manager. A opção fica disponível até o status Pending Developer Release: **você ainda pode ativá-la depois da aprovação da Apple, enquanto a versão espera seu lançamento manual.** Depois que a versão é aprovada, o status Ready for Distribution dela aparece com a indicação "Phased Release". No fim dos 7 dias, os Admin e App Manager do app recebem uma notificação. ### Pausar, retomar e liberar para todos - **Pausar**: até 30 dias no total, quantas vezes você quiser. Uma pausa de 10 dias deixa 20 dias para as próximas. - **Retomar**: o lançamento recomeça do dia em que você parou. - **Liberar para todos**: o botão Release to All Users, no canto superior direito da versão, envia a atualização para todos os aparelhos com atualização automática. - **Remover da venda**: interrompe o lançamento de vez, inclusive se a sua assinatura do programa de desenvolvedor expirar. Se o app voltar à venda, a versão fica disponível para todos de uma vez. Depois de liberar para todos, não dá para ajustar mais nada, segundo [a tabela de propriedades editáveis](https://developer.apple.com/help/app-store-connect/reference/app-information/required-localizable-and-editable-properties). O Nolera 1.0.2 saiu sem lançamento gradual. Veja como eu usaria durante a semana: | O que você vê | O que você faz | O que acontece | | ----------------------------------------- | ----------------------- | -------------------------------------------------- | | Crashes ou avaliações preocupantes | Pausa | As atualizações automáticas param | | A correção está pronta | Nova versão | Ela volta para revisão, com seu próprio lançamento | | Nada fora do normal depois de 3 ou 4 dias | Release to All Users | Todo mundo recebe | | Você espera uma resposta da Apple | Pausa, 30 dias no total | Retoma do dia em que você parou | Durante uma pausa, os downloads manuais continuam. **Marque o lançamento gradual em toda versão que mexe no pagamento ou na primeira abertura do app**: é aí que um defeito custa mais caro, e você não vai poder voltar atrás. ## Quando a correção é urgente: a revisão acelerada A Apple permite pedir uma [revisão acelerada](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review). Ela é reservada a urgências de verdade: um bug crítico para corrigir, ou um lançamento ligado a um evento. 1. Primeiro envie sua versão. Descreva o bug no campo Notes destinado ao revisor. 2. Preencha o formulário de pedido de revisão acelerada e escolha seu app e a plataforma. 3. A Apple acelera a revisão conforme a disponibilidade dela. Nada é garantido. Para um evento, informe nas notas a data dele e qual é a sua relação com ele. Os prazos habituais estão em [o prazo de aprovação da App Store](https://devoria.fr/pt-br/blog/prazo-aprovacao-app-store-quanto-tempo). ## O que volta para revisão, e o que não volta | Mudança | O que é preciso | | ------------------------------------------------------ | ------------------------------------------- | | Código nativo, permissões, versão do SDK | Novo build, nova versão, revisão completa | | Capturas de tela, descrição, palavras-chave, novidades | Uma nova versão, revisada junto com ela | | Texto promocional | Nada: muda sem novo envio | | Pausar, retomar, liberar para todos | Nada: são ajustes de lançamento | | Cabeçalho da página no iOS 27 | Sozinho no Asset Library, ou com uma versão | | Correção em JavaScript, com Expo | Dá para fazer uma atualização remota | O texto promocional muda sem novo envio, segundo a página de informações da versão. Com Expo, uma atualização remota muda o JavaScript, os textos e as imagens sem passar pela App Store. [A documentação do Expo](https://docs.expo.dev/eas-update/introduction/) impõe dois limites: código nativo, permissões e versão do SDK exigem um novo binário, e as atualizações precisam respeitar as regras da App Store. ### Meu caso: uma correção remota que o revisor nunca viu Em setembro de 2026, um build do Nolera estava esperando revisão. Eu tinha corrigido um defeito na tela de escaneamento e publicado essa correção como atualização remota durante a espera. O build foi rejeitado mesmo assim, por causa desse defeito já corrigido. A explicação está na [documentação do expo-updates](https://docs.expo.dev/versions/latest/sdk/updates/): por padrão, o app baixa a atualização ao abrir e aplica na abertura seguinte. O revisor instala o app, abre uma vez e testa o código embutido no build. **A mesma regra vale para seus novos usuários: a primeira sessão deles roda o código do build.** Desde então, qualquer mudança na tela inicial, no paywall ou na funcionalidade principal vai num novo build. A atualização remota só serve para quem já tem o app. ## Zerar a nota com uma versão Toda nova versão oferece a opção Reset rating when this version is released. Segundo [a ajuda da Apple sobre zerar a nota](https://developer.apple.com/help/app-store-connect/monitor-ratings-and-reviews/reset-an-app-overview-rating), ela vale para todos os países, mantém as avaliações escritas e não pode ser desfeita depois do lançamento. A Apple recomenda usar com moderação, porque uma página com poucas notas pode desanimar. ## O checklist antes de enviar sua atualização - O número de versão é maior, o build foi incrementado. - O build foi testado no TestFlight, num iPhone pequeno e no iPad se o seu app roda nele. - As novidades estão escritas em cada idioma, e as mudanças importantes estão listadas. - As capturas de tela mostram a interface atual, se ela mudou. - As notas para o revisor dizem o que mudou e onde encontrar. - A opção de lançamento está escolhida: manual se você precisa cumprir uma data. - O lançamento gradual está marcado se a versão mexe no pagamento ou na primeira abertura. - Você sabe se uma eventual correção pode ir por atualização remota, ou se vai exigir um build. ## Passar na revisão a cada atualização Toda atualização passa de novo pelo App Review, e uma rejeição trava sua correção. O [Review Kit](https://devoria.fr/pt-br/kits/app-review) reúne meu checklist antes do envio, minhas rejeições corrigidas e duas skills do Claude Code que revisam seu projeto e sua página, e depois preparam sua resposta se a Apple rejeitar. O caminho completo está na página [publicar um aplicativo na App Store](https://devoria.fr/pt-br/expertise/publicar-app-na-app-store). Se você está preparando seu primeiro lançamento, [faça seu diagnóstico gratuito](https://devoria.fr/pt-br/diagnostic): ele coloca as etapas em ordem e te envia meu checklist anti-rejeição da Apple. ## Perguntas frequentes ### Quanto tempo dura o lançamento gradual na App Store? Sete dias: 1% dos usuários com atualização automática no primeiro dia, depois 2, 5, 10, 20 e 50%, e 100% no sétimo. Você pode pausar por até 30 dias no total, ou encerrar a qualquer momento com Release to All Users. ### Uma atualização de app iOS passa de novo pela revisão da Apple? Sim. Toda nova versão, com seu build e seus metadados, passa pelo App Review. Já o texto promocional e os ajustes de lançamento mudam sem novo envio. ### Dá para voltar para a versão antiga de um app na App Store? Não. É preciso criar uma nova versão, com a correção, e enviá-la para revisão. É por isso que o lançamento gradual e a pausa dele são úteis. ### Os novos usuários recebem a atualização durante o lançamento gradual? Sim, se baixarem o app na App Store. O lançamento gradual só controla as atualizações automáticas: qualquer pessoa pode baixar a nova versão a qualquer momento. ### Dá para ativar o lançamento gradual depois da aprovação da Apple? Sim, enquanto a versão estiver com status Pending Developer Release, ou seja, em lançamento manual e ainda não publicada. Depois que a versão sai, é tarde demais para essa versão. ### O que colocar nas notas de versão de uma atualização? As novas funcionalidades e as mudanças importantes, listadas com clareza: é a regra 2.3.12. Para uma simples correção de bugs, de segurança ou de desempenho, uma frase genérica basta. O campo aceita 4.000 caracteres e pode ser traduzido em cada idioma. ## Seu projeto [Review Kit](https://devoria.fr/pt-br/kits/app-review): Meu checklist de revisão da App Store, as recusas da Apple que corrigi, o checklist do Google Play e três skills do Claude Code. R$ 289. [iOS & Android Kit](https://devoria.fr/pt-br/kits/ios): Crie seu app para iPhone e Android com o Claude Code: o código inicial dos meus apps, o caminho até as lojas e todos os kits. R$ 589. [Diagnóstico: o que te separa do seu app de iPhone](https://devoria.fr/pt-br/diagnostic): 7 perguntas, 60 segundos: descubra o que realmente te impede de publicar seu app de iPhone, seu caminho em 4 etapas e o kit certo para você.