Lançamento em fases na App Store: o rollout de 7 dias, quando pausar e como lançar uma correção (2026)

O lançamento em fases da App Store envia uma atualização de versão para uma parcela crescente dos usuários com atualizações automáticas ativadas ao longo de sete dias, começando em 1% no primeiro dia e chegando a 100% no sétimo. Se você acompanhar crashes e e-mails de suporte todos os dias e pausar assim que algo parecer errado, uma build com problema atinge um grupo pequeno de pessoas, e não toda a sua base de usuários. Mas o lançamento em fases tem uma grande limitação: ele só controla as atualizações automáticas. Qualquer pessoa ainda pode baixar a nova versão manualmente.

O que o lançamento em fases da App Store controla e o que ele não controla?

O lançamento em fases controla apenas quais usuários com atualizações automáticas ativadas recebem sua atualização de versão, e quando. Ele não esconde a nova versão de downloads manuais e não reverte quem já a instalou.

Segundo a Ajuda do App Store Connect da Apple, "uma amostra aleatória de usuários com atualizações automáticas em dispositivos qualificados receberá a atualização, sem qualquer notificação sobre sua participação no lançamento em fases". O recurso funciona para atualizações de versão de iOS, macOS e tvOS, então não dá para usá-lo no primeiro lançamento de um app. Para configurá-lo, é preciso ter a função Account Holder, Admin ou App Manager. A Apple também afirma: "Apps e atualizações de apps em lançamento em fases podem ser baixados manualmente da App Store por qualquer pessoa a qualquer momento."

Qual é o cronograma do lançamento em fases da App Store?

Em novembro de 2026, o cronograma é fixo em 1%, 2%, 5%, 10%, 20%, 50% e 100% ao longo de sete dias, e não pode ser editado. O que você controla é quando pausar e quando pular direto para 100%.

Trate cada dia como um checkpoint que termina com uma única decisão: seguir em frente ou pausar.

Como ativar o lançamento em fases no App Store Connect?

O lançamento em fases é ativado na página da versão, em Phased Release for Automatic Updates, a qualquer momento antes de a atualização entrar no ar. Você não precisa decidir antes de enviar para revisão.

A Apple permite ativá-lo enquanto a versão está em Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected ou Metadata Rejected.

1. Em Apps, selecione seu app e clique na versão que você está enviando na barra lateral.
2. Role até Phased Release for Automatic Updates.
3. Selecione Release update over a 7-day period using phased release.
4. Clique em Save. Após a aprovação, o status mostra Ready for Distribution com Phased Release ao lado.

Você também pode gerenciar lançamentos em fases pela App Store Connect API, o que ajuda se o seu pipeline de release já for automatizado por scripts.

Quando pausar um lançamento em fases e como funciona o limite de 30 dias?

Pause assim que um dos gatilhos combinados previamente for disparado. As pausas podem somar até 30 dias no total e, ao retomar, o rollout continua a partir do dia em que parou.

Registre seus gatilhos por escrito antes do dia do lançamento, para que ninguém fique discutindo enquanto os usuários estão esbarrando no bug. Bons gatilhos são concretos: as sessões sem crash caem abaixo da linha de base da versão anterior, o checkout ou o login falham em uma parcela mensurável das tentativas, ou vários usuários relatam o mesmo bug.

Para pausar, abra a versão em Ready for Distribution, selecione Pause Phased Release e clique em Save. Para retomar, selecione Use Phased Release. O exemplo da Apple: se você pausar por 10 dias e depois retomar, restam 20 dias de pausa. Você pode pausar quantas vezes quiser dentro desse total. Para pular as fases restantes, clique em Release to All Users no canto superior direito da página da versão.

Como fica um lançamento em fases quando aparece um bug?

Quando aparece um bug, você pausa, corrige e lança uma nova versão, de novo com o lançamento em fases ativado. Os usuários que ainda aguardam atualizações automáticas continuam na versão anterior enquanto você trabalha.

Imagine que a versão 3.4 substitui seu mecanismo de sincronização. No primeiro dia, 1% dos usuários com atualização automática a recebe, e você verifica duas vezes o seu crash reporter e os logs de erro de sincronização. No terceiro dia, em 5%, surge uma concentração de falhas de sincronização em uma versão mais antiga do iOS. Você pausa na hora. Muito menos usuários são afetados do que se todos tivessem recebido a atualização, e os usuários com atualização automática que ainda não foram alcançados continuam na 3.3.

Em seguida, corrija o bug e envie a 3.4.1 com o lançamento em fases ativado. Teste a correção em uma build de release, não só em debug; nosso plano de testes em build de release cobre essa etapa. Diga claramente nas notas da versão 3.4.1 que a sincronização foi corrigida; nossos exemplos de notas de versão mostram como. Se a correção for urgente e você confiar nela, use Release to All Users após a aprovação em vez de esperar mais uma semana.

Mais uma proteção: coloque o novo mecanismo de sincronização atrás de uma flag no servidor. Pausar impede que a atualização se espalhe, mas uma flag permite desligar o código arriscado para quem já instalou a 3.4. Os dois funcionam muito bem juntos.

O que outros desenvolvedores enfrentaram ao pausar um lançamento em fases?

Discussões públicas mostram o mesmo padrão: desenvolvedores pausam uma versão com bug e depois ficam sem saber o que um novo lançamento em fases faz com os usuários que já a receberam. A documentação da Apple não responde a isso, então planeje como se a correção precisasse do seu próprio rollout.

• Um desenvolvedor nos Apple Developer Forums relatou que "notou um crash, pausou o rollout da atualização, corrigiu o app, fez o upload e iniciou outro rollout em fases" com menos de 10% dos usuários na build com problema. Ele perguntou se os mesmos usuários receberiam o novo rollout. A discussão nunca teve uma resposta oficial; uma das respostas disse que os usuários da 8.0 "devem ser avisados de que há uma atualização 8.1 disponível assim que ela for lançada".
• Em outra discussão do fórum, um desenvolvedor contou que "parou em 1%" na versão 15.0.1 por causa de um bug crítico e queria escalonar também a 15.0.2, na esperança de que a 15.0.1 fosse "praticamente pulada pela maioria dos usuários". Uma resposta anterior nessa discussão sugeria pedir uma revisão acelerada enquanto a versão com bug estava pausada e, possivelmente, tirar o app da venda "para que nenhum usuário novo pegue a versão com problema". Antes de fazer isso, lembre-se da regra de remoção da venda no aviso acima.
• A equipe de ferramentas de release por trás das notas store-quirks da Tramline documenta que iniciar um novo release "simplesmente cancela o rollout existente", e a versão anterior passa para REPLACED_WITH_NEW_VERSION com seu lançamento em fases marcado como COMPLETE. As mesmas notas dizem que uma pausa "não pode fazer nada em relação aos usuários que já receberam a atualização".

Nos três casos, pausar só serviu para ganhar tempo. A correção sempre foi uma nova versão, e ninguém pôde contar com o mesmo grupo sendo atualizado primeiro. É por isso que flags no servidor e uma branch de hotfix que você consiga lançar rapidamente importam mais do que o botão de pausa.

Como o lançamento gradual do Google Play se compara?

O lançamento gradual do Google Play usa uma porcentagem que você escolhe e aumenta manualmente. Depois de uma interrupção, a retomada atinge o mesmo grupo de usuários. Planeje os rollouts das duas lojas separadamente.

De acordo com a Ajuda do Play Console, "a porcentagem do lançamento gradual do seu app não aumenta automaticamente", e os lançamentos graduais "só podem ser usados para atualizações de apps, não ao publicar um app pela primeira vez". Após uma interrupção, os usuários que já receberam a versão continuam nela, e o Google recomenda lançar uma nova versão com um bundle corrigido em vez de retomar uma versão quebrada. Os lançamentos de produção podem ser limitados a países específicos, mas, depois de iniciados, não é possível remover países. Se a sua próxima atualização Android também precisa atender ao novo target SDK, veja nosso guia sobre o nível de API 36 no Google Play.

O que verificar antes de iniciar um lançamento em fases?

Antes de o rollout começar, confirme que o lançamento em fases está salvo na versão, que suas linhas de base e gatilhos de pausa estão registrados por escrito e que uma correção pode ser lançada rapidamente. Use este checklist:

• Lançamento em fases selecionado e salvo na página da versão
• Dashboards de crash e de erros do backend nos favoritos, com linhas de base da versão anterior
• Gatilhos de pausa por escrito, combinados com todos que podem apertar o botão
• Recursos arriscados atrás de flags no servidor
• Uma pessoa responsável verificando as métricas em cada um dos 7 dias
• Uma branch de hotfix pronta, além do nosso checklist de envio para a App Store para a build seguinte
• Mudanças na página da loja seguradas até o rollout chegar a todos

Se preferir delegar o próprio lançamento, nosso serviço de envio para a App Store cobre a configuração do App Store Connect e do Play Console, a preparação para a revisão e os lançamentos nas duas lojas por $599 (as taxas das contas de desenvolvedor são cobradas à parte). Para uma segunda opinião sobre uma atualização arriscada, envie um e-mail para yagyeshsrbobde@gmail.com com o seu app e o que está mudando.