Publicar um app parece o fim do trabalho quando o time olha apenas para o botao de subir binario na loja. Na pratica, a publicacao comeca antes: identidade do app, versao, build, permissao, API, politica de privacidade, screenshots, teste interno e plano de observacao depois do release. Quando esse preparo nao existe, a equipe descobre o problema na pior hora: build rejeitado, link quebrado, permissao sem explicacao, endpoint antigo ainda em uso ou tela que fica ruim em aparelho real.
Para um app corporativo em React Native, a publicacao precisa ser tratada como etapa operacional, nao como formalidade. O mesmo cuidado que voce usa em deploy web precisa aparecer aqui: evidencias, ambiente certo, teste repetivel e criterio para liberar producao.
Este guia organiza um checklist realista para Android e iOS, aproveitando o fluxo com Expo e EAS sem confundir build tecnico com app pronto para loja.
1. Release comeca antes do upload
Muita gente pensa em publicacao apenas quando o binario ja esta pronto. O problema e que varios erros de loja nascem bem antes: nome ruim, package trocado, bundle identifier improvisado, permissao sobrando, politica de privacidade ausente ou fluxo principal sem teste em aparelho real.
Antes do primeiro upload, o time deveria responder:
- qual problema o app resolve hoje sem depender de explicacao manual?
- qual e o fluxo principal que precisa funcionar em Android e iOS?
- quais permissoes o app realmente usa?
- qual ambiente de API vai receber usuarios reais?
- quem testa cada build antes de enviar para loja?
- o que acontece se o backend mudar enquanto usuarios antigos continuam com versao instalada?
Sem essas respostas, a loja vira o primeiro ambiente de descoberta de defeitos. E isso costuma sair caro em atraso, revisao e desgaste com quem esta esperando o app.
2. Feche a identidade do app antes de crescer o historico
A configuracao do Expo deixa claro que `ios.bundleIdentifier` precisa ser unico na App Store, e que `android.versionCode`, `ios.buildNumber` e outros campos fazem parte do contrato de release. Isso significa que nome, slug, bundle identifier e package nao deveriam ser tratados como detalhe visual.
O minimo que precisa ficar estavel cedo:
- nome publico do app;
- slug do projeto;
- `ios.bundleIdentifier`;
- `android.package`;
- icone e splash coerentes com a marca;
- scheme ou deep link principal;
- owner correto do projeto Expo quando houver time.
Se o projeto nasce confuso nessa identidade, depois aparecem problemas em links, credenciais, loja, push, analytics e atualizacoes. O artigo Expo, development build e EAS Build ajuda a organizar essa base antes do release.
3. Versione para gente real, nao para a sua memoria
No app config da Expo, `expo.version` representa a versao que o usuario enxerga, `ios.buildNumber` corresponde ao `CFBundleVersion` e `android.versionCode` precisa ser incrementado a cada release no Google Play. Isso ja mostra uma verdade importante: publicar sem rotina de versionamento convida erro manual.
Uma rotina simples costuma funcionar bem:
- `version` para a versao funcional comunicada ao usuario;
- `ios.buildNumber` para cada binario novo no iOS;
- `android.versionCode` para cada binario novo no Android;
- registro do commit e da API usada no release.
Erros comuns:
- subir um novo binario sem incrementar build number;
- esquecer versionCode no Android;
- mudar JavaScript com EAS Update sem conferir compatibilidade de `runtimeVersion`;
- nao registrar qual backend estava ativo no teste final.
Quando a equipe faz isso no improviso, o suporte recebe bug sem saber exatamente qual build esta instalada no aparelho.
4. Entenda o papel do App Bundle no Android
A documentacao oficial do Android informa que novas apps no Google Play precisam ser publicadas com Android App Bundle e que o Google Play usa esse bundle para gerar APKs otimizados por dispositivo. Para quem publica app corporativo, isso reduz gestao manual de multiplos APKs, mas tambem exige disciplina no artefato enviado.
Na pratica, vale conferir:
- se o build Android gerado e mesmo o artefato de publicacao;
- se o package esta definitivo;
- se as permissoes batem com o comportamento real do app;
- se o tamanho e os assets estao razoaveis;
- se o backend de producao esta pronto para a base inicial.
Em projetos Expo/EAS, o importante nao e decorar o formato. E saber que o arquivo de publicacao Android faz parte da trilha oficial e precisa ser tratado como evidencia de release.
5. TestFlight e distribuicao interna existem para achar problema antes da loja
A Apple descreve o TestFlight como o caminho para beta testing e informa que voce pode designar ate 100 membros da equipe como testadores internos e convidar ate 10.000 testadores externos depois da aprovacao inicial para TestFlight. Isso muda a postura do time: validar antes da App Store nao e luxo, e parte do processo.
Mesmo quando o app ainda nao vai para uma base grande, o fluxo de teste interno precisa responder:
- quem testa Android?
- quem testa iPhone real?
- qual aparelho pequeno foi usado?
- qual build foi validada?
- qual ambiente de API entrou nesse teste?
- quais fluxos sao bloqueadores para release?
Em Android, o raciocinio e o mesmo: usar um caminho de distribuicao interna antes do release aberto ajuda a encontrar permissao negada, layout quebrado, token errado, deep link falhando ou integracao presa em ambiente antigo.
6. Loja nao analisa so codigo, ela analisa presenca
A documentacao de boas praticas da Expo lembra que publicacao envolve app store assets, responsividade, permissoes e presencia do app na loja. Isso inclui screenshots, descricao, categoria, icone, texto de suporte e coerencia entre promessa e tela real.
O `store listing` precisa ser honesto e util:
- screenshots do fluxo real, nao apenas tela bonita isolada;
- descricao clara sobre o uso do app;
- categoria coerente com o produto;
- contato de suporte ativo;
- links publicos corretos para politica de privacidade e suporte.
Um erro comum em app corporativo e copiar descricao generica que nao explica o valor do produto. Outro e prometer funcao que ainda depende de operacao manual ou nao esta pronta em producao.
7. Politica de privacidade e app privacy nao sao opcional
A pagina de boas praticas da Expo registra que apps iOS novos e atualizacoes precisam de politica de privacidade para passar pela revisao da App Store, e que o App Store Connect pede informacoes sobre praticas de privacidade. Em outras palavras: nao basta o app ser util; ele tambem precisa explicar o que coleta e por que coleta.
Para um app corporativo, revise pelo menos:
- quais dados pessoais entram no login, suporte ou operacao;
- se existe analytics, crash reporting ou push;
- se alguma biblioteca coleta dado tecnico adicional;
- se a politica publicada esta coerente com o app atual;
- se a equipe sabe responder o formulario de privacidade sem chute.
Se o app conversa com o backend da empresa, vale alinhar essa camada com o que ja e comunicado no portal, em paginas como politica de privacidade e contato institucional.
8. Permissao precisa bater com uso real e com texto humano
Uma loja tende a estranhar app que pede permissao demais sem explicar contexto. E o usuario tambem. Camera, notificacao, localizacao, arquivos e biometria precisam fazer sentido dentro do fluxo.
Checklist rapido:
- remover permissao que ficou de experimento antigo;
- explicar no app por que aquela permissao e util;
- garantir que o texto de permissao nao seja generico demais;
- testar o comportamento quando a pessoa negar;
- registrar se a funcionalidade degrada com elegancia.
O artigo Notificacoes push em app corporativo mostra bem como permissao fora de contexto enfraquece o produto antes mesmo da primeira rotina do usuario.
9. Release mobile depende da API continuar previsivel
Ao contrario do site, onde quase todo mundo usa a versao mais nova imediatamente, mobile convive com app antigo instalado. Isso exige compatibilidade de backend. Se o app novo depende de endpoint mudado e o app antigo continua no ar, a equipe precisa planejar a transicao.
Antes do release:
- confirme que a API de producao esta pronta para a versao nova;
- verifique se o app antigo ainda funciona no minimo aceitavel;
- evite mudanca quebradora sem janela de transicao;
- registre a versao do app nas chamadas quando isso ajudar suporte;
- mantenha roteiro de rollback funcional no backend.
Esse cuidado conecta publicacao mobile com maturidade de API. Por isso, um material como Checklist para API REST em producao continua relevante mesmo quando o assunto parece ser loja de app.
10. Teste responsividade e fluxo principal em aparelhos diferentes
A Expo destaca que vale testar em tela pequena, tela grande e iPad, porque a loja pode rejeitar app que renderiza mal mesmo quando ele nao tem foco em tablet. Isso vale ouro para times pequenos: nao confie apenas em um unico celular do desenvolvedor.
Monte um roteiro minimo:
- login e logout;
- primeira carga de dados;
- estado sem rede e recuperacao;
- fluxo principal do negocio;
- push ou permissao relevante;
- deep link ou retorno do sistema;
- erro de API com mensagem compreensivel;
- uso em tela pequena e tela maior.
Se a UI quebra, texto some ou botao fica inacessivel, isso precisa ser resolvido antes de qualquer submissao.
11. Planeje rollout, observacao e retorno
Publicar nao e so aprovar binario. E observar o comportamento da versao nova. O time precisa saber que sinais acompanhar nas primeiras horas e primeiros dias.
Vale monitorar:
- falhas de login;
- erros de sincronizacao;
- tempo de resposta das APIs principais;
- crashes ou travamentos reportados;
- push parando de chegar;
- duvidas repetidas de suporte apos update.
Tambem ajuda definir um rollout gradual quando a plataforma permitir, para nao expor toda a base a um problema descoberto tarde. Mesmo em base pequena, a mentalidade de liberar por etapas deixa o release mais controlado.
12. Checklist de publicacao Android e iOS
- Confirmar nome, slug, package e bundle identifier.
- Incrementar `version`, `ios.buildNumber` e `android.versionCode` corretamente.
- Revisar `runtimeVersion` quando houver estrategia com EAS Update.
- Gerar binario certo para Android e iOS.
- Validar build em aparelho real e em pelo menos uma tela pequena.
- Testar login, fluxo principal, offline, permissao e retorno de erro.
- Conferir politica de privacidade, suporte e links publicos.
- Revisar screenshots, descricao e categoria da loja.
- Checar se a API de producao esta compativel com a versao nova.
- Registrar commit, ambiente, evidencias e pessoas que validaram.
- Publicar primeiro para um grupo interno ou controlado quando possivel.
- Acompanhar sinais de erro e suporte logo apos o release.
13. Erros comuns que atrasam a entrega
- trocar package ou bundle identifier tarde demais;
- esquecer build number ou versionCode;
- subir politica de privacidade desatualizada;
- pedir permissao que o app quase nao usa;
- validar apenas em simulador;
- publicar sem combinar versao do app com API;
- usar screenshot que nao representa a tela real;
- tratar loja como etapa burocratica e nao como parte do release.
14. Quando vale parar e revisar a arquitetura
Se a publicacao esta travando por ambiente confuso, binario inconsistente, API instavel, permissao sobrando ou testes sem evidencias, o problema talvez nao esteja na loja. Esteja no processo tecnico do app. Nessa hora, um diagnostico tecnico pode ser mais util do que insistir em tentar submissao ate passar.
Publicar Android e iOS com tranquilidade nao depende de decorar todos os detalhes da loja. Depende de tratar release como operacao confiavel: identidade do app, build repetivel, contexto de privacidade, API previsivel, teste real e observacao depois da liberacao. Quando esse processo amadurece, a loja deixa de ser um susto e vira so mais uma etapa controlada do produto.
Referencias editoriais: Expo app stores best practices, Expo app config, Apple TestFlight e Android App Bundles.
Termos tecnicos desta leitura
Alguns conceitos aparecem com frequencia neste tema. Abrir o glossario ajuda a comparar definicoes, exemplos e leituras relacionadas sem sair do contexto do artigo.