Como publicar um app React Native na Play Store e na App Store: passo a passo de certificados, assinaturas, build e aprovação
Publicar um app React Native nas lojas em 2026 ainda é o ponto onde projetos atrasam, orçamentos estouram e times perdem fôlego. O caminho técnico passa por certificados, assinaturas, builds reprodutíveis e um jogo de conformidade que muda com frequência. Este guia detalha o “como” e o “por quê” de cada etapa para Android (Google Play) e iOS (App Store), antecipando erros comuns, exigências de privacidade e ajustes de build que evitam reprovações. O objetivo é simples: sair do “funciona no simulador” para “aprovado e publicável” com previsibilidade e sem surpresas.
Antes de compilar qualquer binário, garanta as contas corretas: Google Play Console com perfil de organização e Apple Developer Program com acesso a certificados e App Store Connect. Leia as políticas de conteúdo, privacidade e pagamentos in-app das duas lojas. Se o app oferece conteúdos pagos, assinatura ou desbloqueio de recursos, ajuste desde já a estratégia de pagamentos conforme as regras de cada ecossistema para evitar reprovações na análise.
Um bom atalho de planejamento é revisar um checklist de publicação de app nas lojas com foco em requisitos, taxas e políticas. Isso reduz retrabalho e antecipa pendências jurídicas e de privacidade.
Defina identificadores estáveis: o applicationId do Android e o Bundle Identifier do iOS não devem mudar. Planeje a estratégia de versionamento: use versionName para exibição e versionCode incremental no Android; no iOS configure CFBundleShortVersionString e CFBundleVersion. Atualize o alvo de SDK exigido pelas lojas para o ciclo vigente em 2026 (verifique a exigência mais recente antes do envio). Prepare a documentação de privacidade: declaração de coleta/uso de dados, política de privacidade pública e justificativas do App Tracking Transparency, se aplicável.
No Android, a base é o keystore próprio (JKS) e a configuração de assinatura no Gradle. Crie um keystore seguro com alias e senha fortes e armazene as credenciais fora do repositório (por exemplo, em variáveis de ambiente do CI). Configure o signingConfigs e o release no android/app/build.gradle, apontando para o caminho do JKS e senhas via gradle.properties seguro.
Ative o Play App Signing no Google Play Console. Esse recurso guarda a chave de assinatura de distribuição nos servidores do Google e exige o envio da chave de upload, reduzindo riscos de perda do keystore principal. Se já publicou sem Play App Signing, migração requer atenção à exportação da chave. Não compartilhe o JKS em canais inseguros e documente o processo de rotação de chaves para emergências.
No iOS, o combo é Apple Distribution Certificate + Provisioning Profiles associados ao App ID correto. Utilize assinatura automática no Xcode sempre que possível, vinculando a equipe da conta Apple Developer e permitindo que o Xcode gerencie perfis de distribuição e de testes. Para recursos como notificações push, localização, HealthKit ou Sign in with Apple, ative as capacidades no App ID e no projeto. Para push, prefira a chave APNs (Auth Key) em vez de certificados legados, simplificando o pipeline.
Evite o erro clássico: Bundle Identifier no Xcode diferente do cadastrado no App Store Connect. Garanta também que a equipe (Team) selecionada é a mesma que possui os certificados válidos. Se o pipeline usa CI, exporte um arquivo de ExportOptions.plist adequado para distribuição via App Store.
Dica de ouro: trate chaves e perfis como “infra”. Versione apenas referências, nunca os arquivos sensíveis. Em caso de troca de máquina, o tempo para recuperar certificados costuma ser maior do que refazer um build — e é aí que os prazos estouram.
Ative o Hermes para reduzir tamanho e melhorar tempo de inicialização, a menos que um módulo nativo específico exija JSC. Em android/app/build.gradle, garanta minifyEnabled e shrinkResources quando apropriado, com regras de proguard atualizadas para evitar remoção de classes necessárias. Gere o pacote de release AAB com o comando de Gradle no modo release. Antes de enviar ao Play Console, valide o pacote com a ferramenta de verificação local do Android Studio para checar versões, permissões e assinatura.
Otimize o android:exported nos manifests, defina permissões mínimas necessárias e revise dependências que injetam providers e serviços automaticamente. Remova debuggers, logs verbosos e símbolos desnecessários. Se usar NDK, garanta suporte arm64 e teste o tamanho final do AAB.
No iOS, configure o esquema em Release, ajuste o número de versão e build no Xcode, revise Info.plist (uso de câmera, microfone, localização com chaves de NS…UsageDescription específicas) e gere um Archive pelo Organizer. Faça a validação no próprio Xcode e envie para o App Store Connect. Se houver recursos de login social, WebViews ou permissões sensíveis, antecipe descrições claras para a revisão.
Para reduzir surpresas de performance, habilite Hermes também no iOS e teste em dispositivos físicos de 64 bits. Evite builds destinados a simulador ao subir para TestFlight: binários de simulador não são válidos para distribuição.
Automatizar o pipeline com CI/CD e Fastlane reduz variabilidade humana. Separe lanes para testes, beta (TestFlight e internal testing) e produção, parametrizando número de versão, changelog e upload. A automação também ajuda a garantir que o mesmo conjunto de flags e assinaturas seja usado a cada build, evitando o comportamento “funciona na máquina de quem fez”.
Crie a listagem com título, breve descrição e descrição completa. Suba ícone, feature graphic e screenshots em diferentes densidades. Preencha a seção de classificação etária, privacidade e segurança de dados (Data safety), conteúdo direcionado a crianças, além de política de anúncios se aplicável. Informe URL da política de privacidade pública e esteja pronto para justificativas de permissões sensíveis.
Envie um Android App Bundle assinado. Defina trilhas: interna (rapidamente testável), fechada/aberta (beta) e produção. Use a trilha interna para validar integrações de faturamento, links universais e atualizações in-app antes de liberar para um público maior. Garanta versionCode crescente e evite reusar códigos. Se o app depende de atualização de Play Integrity ou SafetyNet, configure a verificação com antecedência.
Se o app monetiza dentro do ecossistema, avalie com cuidado os requisitos de cobrança e conformidade. Há nuances entre carteiras digitais e IAP nas duas plataformas que exigem leitura técnica e jurídica. Para um panorama prático, confira a discussão sobre pagamentos in-app com Pix e carteiras digitais e ajuste a arquitetura desde o início.
Após enviar o Archive, o build aparece no App Store Connect para TestFlight. Configure testadores internos (imediato) e externos (exigem revisão inicial). Use as notas de “O que testar” para orientar feedback e capture crash reports reais de dispositivos, algo que o simulador não revela.
Na ficha do app, preencha título, subtítulo, descrição, palavras-chave, categoria, suporte, política de privacidade, “nutrição de dados” (dados coletados/relacionados a usuário) e, se houver rastreamento, o aviso do App Tracking Transparency com copy clara do motivo do rastreio. Prepare screenshots por dispositivo e, se aplicável, prévias em vídeo. Responda às perguntas de conformidade de criptografia e exportação. Evite menções a plataformas concorrentes na descrição e garanta que links externos abram no navegador adequadamente.
Motivos típicos de reprovação incluem uso de APIs privadas, descrição imprecisa das permissões, experiência quebrada sem login de teste e fluxos de pagamento contrários às diretrizes. Resolva o apontamento, incremente o número de build e reenvie; a velocidade de aprovação melhora quando a correção é objetiva e bem documentada no campo “Notas de revisão”.
Se ainda estiver escolhendo tecnologia para o próximo ciclo, um olhar para comparativo React Native, Flutter e nativo em 2026 ajuda a alinhar desempenho, custos e manutenção com a realidade de publicação nas lojas.
Indica assinatura incorreta ou conflito de versionCode/chaves entre versões já instaladas. Desinstale a versão anterior e valide assinatura com apksigner. Revise o signature v2/v3 nas configurações de build e garanta que a chave de upload está devidamente registrada no Play Console.
Geralmente é erro de assinatura/exportação, Bundle Identifier divergente ou rejeição automática por símbolos de depuração. Revise o ExportOptions.plist, rearchive em Release, confirme equipe correta e verifique e-mails de processamento automático do App Store Connect com logs de falha.
Se a loja aponta coleta de dados não declarada, alinhe o código com o formulário: desative SDKs que coletam além do necessário, ajuste configurações de anonimização e atualize a seção de “nutrição de dados”/“Data safety” para refletir o comportamento real. Divergência entre código e declaração é causa recorrente de rejeição.
Trate publicação como parte do produto, não como “último passo”. Crie uma rotina quinzenal de builds de beta, teste permissões em dispositivos reais, documente respostas padrão para a equipe de revisão e alinhe monetização às políticas desde o design. Se o roadmap prevê recursos avançados, avalie também os impactos de plataforma antes de codar, apoiando-se em materiais como o guia para escolher a melhor plataforma de desenvolvimento.
Para publicação em produção, o formato exigido é o Android App Bundle (AAB). APK geralmente é aceito apenas em contextos específicos de teste interno e instalação direta, não para a listagem pública da Play Store.
Para criar o Archive e enviar ao App Store Connect, é necessário ambiente macOS com Xcode. Serviços de CI em nuvem com macOS podem suprir essa necessidade se não houver máquina local.
Normalmente é um SDK que referencia APIs privadas ou symbols internos do iOS. Atualize dependências, revise pods e evite frameworks ofuscados que façam chamadas não documentadas.
Peça apenas o necessário, inclua mensagens claras de propósito nas UsageDescriptions, explique na listagem por que a permissão é essencial e avalie alternativas que reduzam o escopo (por exemplo, fotos em vez de câmera se fizer sentido).
Use TestFlight para validar em dispositivos reais, coletar crashes e feedback de usabilidade antes da revisão final. Ir direto para produção aumenta o risco de reprovação por problemas que seriam pegos em um beta restrito.
Pronto para dar o próximo passo? Aplique o checklist deste guia no seu pipeline, registre os aprendizados e compartilhe dúvidas nos comentários. Explore também conteúdos aprofundados no appnoodles.com para fortalecer sua estratégia de publicação e evolução contínua do app.
