Atualizacao obrigatoria no app: quando bloquear e como fazer isso sem caos

Mais cedo ou mais tarde, todo app corporativo encontra a mesma pergunta desconfortavel: chegou a hora de obrigar o usuario a atualizar? As razoes variam. Pode ser uma correcao de seguranca, uma mudanca de contrato da API, uma rota antiga que nao faz mais sentido, um bug grave na autenticacao, uma permissao nova ou simplesmente o custo crescente de manter compatibilidade com uma base antiga demais.

O problema e que "obrigar atualizar" parece simples no papel e costuma virar caos quando o time nao decide o que realmente esta protegendo. Alguns apps travam cedo demais e interrompem a operacao. Outros deixam a versao antiga circular por tempo demais e empurram risco para a API, para o suporte e para o usuario final. Entre um extremo e outro, existe uma estrategia mais madura: definir criterios, medir a base, comunicar bem e bloquear apenas quando o risco realmente justificar.

Este guia organiza essa decisao em apps React Native com Expo. O foco e separar soft update de hard update, decidir versao minima suportada, usar o fluxo de updates e build com criterio e desenhar uma tela de atualizacao que reduza atrito sem maquiar urgencia quando o bloqueio for inevitavel.

1. Nem toda atualizacao precisa ser obrigatoria

O primeiro erro comum e tratar qualquer release como se merecesse bloqueio. Em app corporativo, a atualizacao obrigatoria deve ser excecao, nao rotina. Antes de bloquear, pergunte o que esta em jogo:

• corrigir um detalhe visual realmente exige travar a operacao?
• ha risco de seguranca, integridade de dado ou fluxo critico quebrado?
• o backend ainda consegue conviver com a versao antiga por uma janela curta?
• existe update OTA suficiente ou a mudanca exige binario novo?

Quando a resposta e "nao", costuma ser melhor trabalhar com recomendacao de atualizacao, rollout e compatibilidade temporaria. O artigo compatibilidade entre app, API e runtimeVersion ajuda a construir essa convivencia antes de chegar ao bloqueio.

2. Separe soft update de hard update

Essa distincao evita discussao abstrata. Em termos praticos:

• soft update: o app avisa que existe versao nova, mas permite continuar por um periodo;
• hard update: o app bloqueia a continuidade ate que a pessoa instale a versao minima exigida.

Soft update faz sentido quando a equipe quer acelerar adoção sem interromper a rotina. Hard update entra quando manter a versao antiga ficou perigoso ou inviavel. Exemplos tipicos:

• mudanca de seguranca no login;
• contrato da API que deixou de aceitar formato antigo;
• falha grave que pode corromper dado;
• dependencia nativa ou permissao que exige novo binario;
• fluxo regulatorio ou operacional que nao pode rodar errado.

Sem essa separacao, o time tende a banalizar a urgencia ou a bloquear demais cedo demais.

3. Versao minima suportada deve nascer de criterio, nao de irritacao

Se a empresa simplesmente se cansa de manter uma versao antiga e decide bloquear sem medir nada, o bloqueio vira surpresa operacional. A melhor abordagem e definir uma versao minima suportada a partir de evidencias:

• percentual da base ainda na versao antiga;
• tipo de risco associado a ela;
• custo de manter compatibilidade no backend;
• volume de erros ou suporte concentrado nessa release;
• tempo de comunicacao dado para a atualizacao.

Esse criterio dialoga diretamente com os sinais do artigo observabilidade em app React Native em producao. Sem dados por versao, o bloqueio parece arbitrario.

4. Primeiro decida se o problema resolve com OTA update ou com novo build

A documentacao da Expo explica que expo-updates gerencia atualizacoes remotas do codigo da aplicacao, mas sempre respeitando a runtimeVersion. Ela tambem lembra que o update disponivel geralmente e baixado e aplicado no proximo restart, a menos que o app escolha um fluxo manual.

Na pratica, isso significa que voce precisa separar duas situacoes:

• mudanca compativel com o runtime atual: pode ser resolvida via OTA update;
• mudanca que depende de novo binario nativo: exige build novo e distribuicao por loja ou canal interno.

Se a equipe tenta resolver com OTA o que na verdade depende de binario novo, o update nao fecha o problema. O artigo Expo, development build e EAS Build cobre bem essa fronteira.

5. Atualizacao obrigatoria e um fluxo de produto, nao so de infraestrutura

Mesmo quando o bloqueio e tecnicamente correto, a experiencia do usuario importa. Uma tela ruim piora tudo. O app precisa responder pelo menos:

• por que esta pedindo atualizacao;
• se a atualizacao e recomendada ou obrigatoria;
• qual a acao esperada agora;
• como abrir a loja ou o destino certo;
• o que acontece se o usuario tentar voltar.

Em app corporativo, clareza vale mais do que dramatizacao. Mensagens como "erro inesperado" ou "versao invalida" costumam gerar chamado sem contexto. Eufemismo demais tambem nao ajuda quando ha risco real.

6. Use uma fonte central para decidir o gate de versao

O app nao deve espalhar essa regra em varias telas. Vale centralizar uma leitura de politica de versao a partir do backend ou de uma configuracao remota controlada. O desenho minimo costuma ter:

• versao minima suportada por plataforma;
• modo de comportamento: livre, recomendado ou obrigatorio;
• mensagem institucional curta;
• URL da loja ou destino de instalacao;
• prazo ou contexto quando existir soft update.

Esse ponto e importante porque permite reagir sem precisar republicar o app so para mudar a regra do bloqueio. Ao mesmo tempo, a fonte dessa decisao precisa ser simples, auditavel e segura, para nao virar mais uma dependencia opaca.

7. Verifique a versao atual do app com sinais consistentes

Para comparar a versao instalada com a versao minima exigida, o app precisa saber quem ele e de forma confiavel. Em projetos Expo, isso normalmente passa por version, buildNumber e versionCode, alem de runtimeVersion quando a estrategia de update exigir esse contexto.

O artigo publicar app Android e iOS ja amarra esses conceitos do lado de release. Aqui a extensao natural e usar esses sinais na decisao de atualizar e no suporte posterior.

Tambem vale enviar a versao atual do app para o backend nas chamadas mais importantes, para que o suporte consiga diferenciar:

• usuario bloqueado por versao antiga;
• usuario em build nova mas sem restart apos OTA;
• usuario em beta ou staging;
• usuario com comportamento legado ainda dentro da janela de convivencia.

8. Se usar atualizacao manual com expo-updates, faca isso com parcimonia

A documentacao da Expo mostra que o comportamento padrao e verificar updates no startup, com opcoes como ON_LOAD, ON_ERROR_RECOVERY, NEVER e WIFI_ONLY. Ela tambem mostra que e possivel desabilitar a verificacao automatica e usar a API manualmente com checkForUpdateAsync(), fetchUpdateAsync() e depois recarregar.

Ao mesmo tempo, a propria documentacao faz um alerta importante: checar atualizacao consome rede e bateria, e nao faz sentido pollar em loop frequente. Uma boa regra de bolso e verificar no lancamento do app ou quando ele volta ao foreground, e nao em qualquer pequena interacao.

Isso e especialmente util em soft update. O app pode consultar a politica ao iniciar, mostrar um aviso proporcional e, se houver update compativel ja baixado, orientar restart ou reload em um momento controlado.

9. Hard update precisa abrir a loja certa com o minimo de atrito

Quando o bloqueio for inevitavel, a acao precisa ser objetiva. A API Linking.openURL() do React Native existe justamente para tentar abrir uma URL com algum app instalado. Na pratica, ela pode ser usada para direcionar o usuario ao link da loja correspondente ou a outro destino institucional controlado.

Cuidados importantes:

• usar URL correta por plataforma;
• prever falha de abertura e mostrar orientacao alternativa;
• nao mandar para pagina genérica sem explicar o que fazer;
• testar em build real, e nao apenas em modo dev.

Se o projeto ja usa deep links e navegacao externa, o artigo deep links, push e navegacao ajuda a manter esse fluxo consistente.

10. Soft update precisa ter janela e limite claros

Soft update eterno vira banner decorativo. Se a equipe quer de fato aumentar adoção de uma release, vale definir uma pequena politica operacional:

• quando o aviso passa a aparecer;
• por quantos dias a pessoa ainda pode continuar;
• quando o modo recomendado vira obrigatorio;
• quem decide essa transicao;
• quais sinais podem antecipar ou adiar o bloqueio.

Isso evita que a regra exista apenas na memoria de quem fez o deploy. E reduz o risco de o time esquecer uma base inteira convivendo com bug relevante.

11. Atualizacao obrigatoria tambem depende da API estar preparada

Mesmo quando o app mostra a tela certa, o backend precisa responder com coerencia. Dois erros comuns:

• bloquear no app, mas deixar a API aceitar chamadas antigas sem consistencia;
• bloquear a API antes que o app saiba orientar o usuario a atualizar.

O melhor desenho costuma alinhar os dois lados:

• backend mede versoes antigas e ajuda a decidir a janela;
• app recebe politica centralizada de bloqueio;
• API pode devolver sinal claro quando a versao ficou fora da janela;
• cliente traduz esse sinal em interface humana.

Esse alinhamento fecha a costura entre app e backend sem improviso.

12. Kill switch e update gate nao sao a mesma coisa

Um gate de versao controla quem pode continuar usando determinada release. Um kill switch, por outro lado, desativa rapidamente uma funcionalidade especifica quando ela ficou perigosa. Os dois mecanismos podem conviver.

Isso e util porque nem todo incidente exige travar o app inteiro. As vezes o problema mora em um fluxo de upload, em um botao novo ou em uma integraçao opcional. Desligar apenas o trecho de maior risco pode ser muito melhor do que impor hard update geral para toda a base.

Essa estrategia combina bem com feature flags e rollout gradual vistos no artigo de compatibilidade. O importante e nao usar bloqueio total como martelo para todo prego.

13. O que observar antes de ativar bloqueio

Antes de mudar a politica para obrigatoria, vale revisar:

• quantos usuarios ainda estao na versao antiga;
• quais erros ela ainda concentra;
• se a release nova realmente estabilizou;
• se a loja ja propagou a nova versao o bastante;
• se o time de suporte sabe o que responder;
• se o destino da loja abre corretamente nos aparelhos.

Bloquear cedo demais pode interromper operacao de quem ainda nem teve chance real de atualizar. Bloquear tarde demais pode custar mais do que a convivencia temporaria suporta. O ponto bom aparece quando voce troca ansiedade por evidencia.

14. Checklist rapido para atualizacao obrigatoria

1. Confirmar se o problema exige soft update, hard update ou apenas rollout.
2. Separar o que pode ser resolvido por OTA do que depende de novo build.
3. Definir versao minima suportada com criterio mensuravel.
4. Centralizar a politica de bloqueio em uma fonte controlada.
5. Mostrar mensagem humana, curta e proporcional ao risco.
6. Garantir abertura correta da loja ou destino de instalacao.
7. Medir por plataforma, build e versao antes de travar tudo.
8. Alinhar app e API na transicao para modo obrigatorio.
9. Testar o fluxo inteiro em build real.
10. Documentar quem ativa, quem desativa e quais sinais justificam a mudanca.

15. Erros comuns

• tratar toda release como candidata a bloqueio;
• usar hard update para problema que um soft update resolveria;
• exigir build novo quando um OTA compativel bastava;
• deixar o banner de atualizacao viver para sempre sem consequencia;
• nao testar o link da loja em aparelho real;
• bloquear no app sem alinhar o backend;
• forcar update geral quando um kill switch pontual seria suficiente;
• ativar regra por ansiedade, sem medir a base antiga.

16. Quando procurar ajuda tecnica

Se cada atualizacao importante vira discussao improvisada entre app, backend, suporte e operacao, provavelmente o problema nao e apenas uma tela de aviso. Falta um modelo de decisao sobre versao minima, rollout, OTA, build e comunicacao. Nessa hora, um diagnostico tecnico ajuda a organizar o fluxo para que a proxima correcao critica seja tensa no conteudo, mas previsivel na execucao.

Atualizacao obrigatoria madura nao e a que trava mais gente. E a que sabe exatamente quando bloquear, por que bloquear e como guiar a pessoa ate a versao certa com o menor atrito possivel para a operacao.

Referencias editoriais: Expo Updates, Expo Runtime versions and updates, Expo Deploy updates e React Native Linking.