React Native: um guia definitivo para publicar seu aplicativo

Em outras palavras, são arquivos que contêm todo o código e recursos do seu app, já compilados na linguagem nativa de cada plataforma, prontos para serem distribuídos e instalados nos dispositivos dos(as) usuários(as).

Sem gerar um APK ou IPA, você não consegue sair do ambiente de desenvolvimento e colocar seu app “de verdade” em um celular ou na loja.

Por que eles importam? Porque são esses arquivos que você vai entregar para as lojas de aplicativos (Google Play Store no Android, App Store no iOS) ou distribuir diretamente para testers. Pense neles como o produto final do seu trabalho de desenvolvimento: sem eles, seu app fica preso no seu computador.

Cada plataforma tem seu formato porque Android e iOS são sistemas diferentes – o React Native cuida para que, com o mesmo código JavaScript, consigamos gerar ambos.

Mas o resultado final precisa ser empacotado adequadamente para cada sistema. Em suma: gerar o APK/IPA é transformar seu app em um arquivo instalável, etapa obrigatória para publicá-lo ou compartilhá-lo.

Como funciona o processo de build no React Native

Você já tem o app rodando no simulador/emulador, possivelmente usando npm start ou expo start. Porém, rodar em modo de desenvolvimento é diferente de gerar a build de produção. Vamos entender como pegamos nosso código e transformamos em APK/IPA: isso é o processo de build.

Build com Expo (React Native com Expo)

Se você iniciou seu app com Expo (Expo CLI), boa notícia: o Expo simplifica muita coisa, inclusive a geração dos executáveis.

O Expo é uma plataforma que cuida de detalhes nativos para você. Antigamente usávamos comandos como expo build:android e expo build:ios para gerar APK e IPA.

Hoje, o Expo evoluiu para usar o EAS (Expo Application Services), que permite builds na nuvem com comandos como eas build (você faz login no Expo, envia o projeto e eles compilam nos servidores deles).

O fluxo básico é: configurar algumas infos do app (nome, ícone, versão, IDs de pacote etc.) no arquivo app.json/app.config.js, depois rodar o comando de build. O Expo vai pedir algumas informações (por exemplo, criar credenciais de assinatura, como a keystore Android ou certificados iOS – o que ele pode ajudar a gerar automaticamente). Após alguns minutos, ele fornece os arquivos finais prontos para download.

A grande vantagem é não precisar abrir Android Studio ou Xcode para nada disso. Uma dica valiosa: a cada atualização do Expo, o processo de build pode mudar um pouquinho, então consultar a documentação oficial do Expo é sempre recomendado.

A doc explica o passo a passo atualizado para gerar APK/IPA via Expo, incluindo comandos do EAS. Em resumo, o Expo te dá um caminho “feliz” para gerar builds, ótimo para quem não quer mexer com muitos detalhes nativos no início.

Como testar seu app antes de publicar oficialmente

Beleza, você gerou seu APK/IPA. Publicar direto nas lojas agora? Calma lá! É altamente recomendável testar bastante o app fora do ambiente de desenvolvimento antes do lançamento oficial.

Isso inclui testar no seu próprio dispositivo físico, talvez enviar para alguns amigos(as) ou testers de confiança, e utilizar versões de teste internas nas lojas. Aqui vão algumas formas de testar:

• Emulador/Simulador: Provavelmente você já usou durante o desenvolvimento (Android Emulator, iOS Simulator). Eles são ótimos para desenvolvimento, mas não pegam tudo – desempenho real, comportamento de câmera, sensores, etc., às vezes só sentindo no aparelho físico.

• No seu dispositivo localmente: Nada como rodar no celular de verdade. No Android, você pode simplesmente pegar o APK gerado (ou um build de depuração mesmo) e instalar no aparelho.

Talvez você precise habilitar a instalação de fontes desconhecidas nas configurações de segurança do Android (para poder instalar um APK fora da Play Store). Depois é só tocar no APK no dispositivo e instalar.

Verifique se tudo funciona: acesso à internet, login, a UI em diferentes tamanhos de tela, etc.

No iOS, instalar diretamente é mais complicado – sem publicar, você geralmente precisa conectar o iPhone no Xcode e rodar via cabo (usando seu certificado de desenvolvedor) ou então usar TestFlight (falaremos já já).

Há também a opção de distribuição Ad Hoc (gerando um IPA assinado para dispositivos específicos cadastrados pelo UDID), mas para iniciantes o TestFlight costuma ser mais simples.

• Teste de usabilidade e correção de bugs: Use esse período de testes internos para caçar bugs que não apareceram no desenvolvimento.

Uma dica é gerar builds de “Release” (modo produção) para testar, e não só builds de “Debug”. No React Native, o modo Release desativa algumas verificações e ferramentas de debug, então se algo só quebraria em produção, é bom pegar agora. Veja desempenho, comportamento offline, etc.

• Feedback de amigos/testers: Se possível, convide algumas pessoas para usar seu app e dar feedback. Muitas vezes, outro par de olhos pega problemas de usabilidade que você, como pessoa desenvolvedora, nem percebe porque já está acostumado(a).

Você pode enviar o APK pra eles (no Android) ou adicionar no TestFlight (iOS) ou até usar ferramentas de distribuição beta como veremos.

Distribuindo versões de teste – TestFlight e Google Play Console

Uma vez que você já testou internamente, provavelmente vai querer distribuir uma versão beta para mais gente testar – sem ainda torná-la pública para todo mundo.

As próprias plataformas oferecem meios para isso: no iOS temos o TestFlight, e no Android o Google Play Console tem os tracks de teste (Interno, Fechado, Aberto). Vamos entender cada um.

TestFlight (beta testing no iOS)

O TestFlight é a ferramenta oficial da Apple para distribuir apps em beta. Com ele, você envia seu app para a App Store (em uma seção de Testes) e convida usuários para testarem antes do lançamento.

Em vez de mandar um IPA por aí (o que seria complicado, porque instalá-lo exige procedimentos chatos no iOS), você simplesmente cadastra os emails dos testers ou gera um link público de convite.

Os testers baixam o app TestFlight na App Store (é um app da Apple) e por lá conseguem instalar seu aplicativo beta. Simples assim, sem gambiarra de cabos ou UDIDs.

No seu lado, desenvolvedor(a), como funciona? Você precisa ter uma conta de desenvolvedor Apple ativa. No Xcode, depois de fazer o Archive do app, você pode subir a build diretamente para o App Store Connect (que é o portal da Apple).

Lá, você cria uma entrada para TestFlight, define algumas informações (o que testar, notas da versão) e escolhe os testers. Existem dois tipos de testers no TestFlight: os internos e os externos.

• Testadores internos: até 100 pessoas que fazem parte da sua equipe no App Store Connect (geralmente membros do time de desenvolvimento ou clientes próximos). Essas pessoas podem receber o app assim que você o envia, sem precisar de aprovação da Apple. É imediato, bom para distribuir entre co-workers, por exemplo.

• Testadores externos: até 10.000 pessoas que você pode convidar via email ou link público. Esses são “externos” porque não têm acesso à sua conta de desenvolvedor(a).

Antes de liberar para eles, a Apple revisa sua build beta (isso mesmo – uma mini avaliação para garantir que não é nada absurdamente fora das diretrizes básicas).

Essa revisão de beta costuma ser mais rápida/flexível que a de app final, mas existe. Aprovado o beta, os externos podem instalar.

Com link público, você pode simplesmente divulgar e qualquer um com iPhone pode entrar no teste (até atingir o limite).

Os testers poderão instalar a versão de teste e, pelo próprio TestFlight, enviar feedbacks, reportar bugs e até mandar capturas de tela com comentários para você. Ah, importante: builds no TestFlight expiram em 90 dias.

Ou seja, uma versão beta não pode ser usada indefinidamente – é bom atualizar com novas builds se o teste se estender, ou então lançar de fato na loja oficial após esse período.

A Apple faz isso para garantir que betas não fiquem rolando eternamente sem virarem produto final (e também para que os testers sempre usem builds relativamente recentes).

Google Play Console (tracks de teste no Android)

No Android, a Google oferece um sistema de faixas de distribuição dentro do Google Play Console. Você provavelmente já criou uma conta de desenvolvedor(a) Google (pagando a taxa única de $25).

Com seu APK ou AAB em mãos, você vai no Google Play Console e cadastra um novo app (preenche nome, descrição etc., mas pode ser algo provisório só para teste mesmo).

Em vez de publicar direto para todos, você vai usar as faixas de teste: Interna, Fechada (Alpha/Beta) ou Aberta.

• Teste interno: É a faixa mais rápida e limitada. Permite distribuir rapidamente a sua app para um grupo pequeno (até 100 testers) sem precisar passar por aprovação de review do Google.

Ideal para compartilhar builds frequentes dentro do time ou com um grupo muito restrito. Você faz o upload da APK/AAB, marca como versão de teste interna e adiciona os emails dos testers (ou gera um link).

Em questão de minutos, essa versão fica disponível para os testers através da Play Store (eles receberão um link para “participar do teste” e depois podem baixar o app pela loja normalmente, como se estivesse publicado, só que oculto do público).

É super rápido – builds disponibilizadas em segundos após upload – e não exige passar por todo o processo de revisão pública. Use o interno para QA inicial e iterações rápidas.

• Teste fechado (Alpha/Beta): Aqui você pode configurar grupos maiores ou testes externos em fases. Por exemplo, um grupo Beta com, digamos, 500 usuários interessados em testar.

Você libera nessa faixa e, geralmente, o Google faz uma revisão (sim, o Google Play também analisa apps, embora seja menos rigoroso que a Apple). Depois de aprovado, os testers podem acessar via link ou convite.

Você pode ter listas de testers ou até comunidades do Google Groups para gerenciar quem entra. O Beta fechado não aparece abertamente na Play Store, é só para quem for convidado. Útil para expandir um pouco os testes com usuários reais mas ainda controlar o acesso.

• Teste aberto: Esse é praticamente um soft launch – você disponibiliza o app como “Beta público” na Play Store. Qualquer usuário(a) que encontrar sua página (ou via link que você divulgar) pode entrar no teste e instalar.

A diferença para um lançamento final é que a página do app terá um aviso de que é um beta, possivelmente instável. Avaliações feitas durante beta não ficam públicas (salvas separadamente).

Esse modo é bom quando você já quer testar escala maior, ou quando o app já está quase pronto mas você quer colher feedback final de um público amplo antes do lançamento oficial. Aqui também normalmente passa por uma revisão do Google na primeira vez.

O Google Play Console permite que você acompanhe instalações, feedbacks e crashes (integrado com Google Play Console vitals). É quase como publicar o app, só que controlando o público. E um bônus: se você já está usando Firebase Crashlytics no app, mesmo em testes pela Play Console você receberá relatórios de falhas detalhados. Uma vantagem do Android sobre iOS é que, tecnicamente, você não precisa usar o Play Console para distribuir testes – como dito, pode mandar o APK diretamente para alguém instalar.

Mas usar o Play Console torna tudo mais profissional e conveniente: os testers recebem updates automáticos via Play Store quando você envia uma nova versão, e você garante que estão todos na mesma versão, além de evitar aquele passo de “ativa fontes desconhecidas” para pessoas menos tech-savvy.

Ainda assim, para uma distribuição rapidinha dentro do seu time, enviar o APK pelo Slack/WhatsApp e instalar manualmente funciona, claro. Dica: mantenha suas faixas de teste atualizadas com as correções que for fazendo.

O ideal é começar no Interno (rapidamente ver se não quebrou nada grave), depois promover para um Beta fechado ou aberto.

O Google até recomenda rodar um teste interno antes de qualquer lançamento, nem que seja só você como tester, para garantir que o pacote gerado está ok.

Firebase App Distribution – turbo nos seus betas

Além das soluções oficiais das lojas, existe uma alternativa super útil da própria Google (via Firebase) chamada Firebase App Distribution.

Pense nela como um “centrinho” para distribuir builds para testers de forma unificada, seja Android ou iOS, sem precisar publicar nas lojas ou criar links de TestFlight/Play Console manualmente.

É especialmente útil se você quer distribuir versões frequentes (nightly builds, por exemplo) ou para equipes de QA e beta testers constantes.

Como funciona?

O Firebase App Distribution permite que você faça upload de um APK/AAB (Android) ou IPA (iOS) para o Firebase, selecione uma lista de testers (emails ou grupos), e ele cuida de notificar essas pessoas que uma nova versão está disponível. Os testers recebem um email com instruções para instalar.

No Android, geralmente eles baixam e instalam o APK (o Firebase pode alavancar o Internal App Sharing do Google Play nos bastidores, tornando a instalação bem simples).

No iOS, o tester precisará instalar um perfil especial ou um aplicativo auxiliar do Firebase (há um processo de confiança semelhante ao TestFlight, mas sem passar pela App Store – é um meio termo chamado enterprise distribution ou adhoc, gerenciado pelo Firebase).

A ideia central é agilidade e centralização: você consegue gerenciar tanto testers de Android quanto de iOS na mesma plataforma, ver quais versões foram distribuídas, quem já baixou, e até receber feedbacks e relatórios de crash integrados.

Conforme a documentação oficial, o Firebase App Distribution torna a distribuição para testers “indolor”, colocando seu app nos dispositivos rapidamente para obter feedback rápido.

Se você já usa o Firebase Crashlytics, ele se integra muito bem: todo build distribuído já começa a reportar crashes dos testers no console, então você tem métricas de estabilidade junto com a distribuição.

Outra vantagem é que não precisa publicar nada nas lojas – perfeito para apps em desenvolvimento inicial que você não quer subir no store ainda só pra testar.

E diferente do TestFlight/Play Console, aqui não há limite rígido de 90 dias ou de usuários(as) tão estritamente (há limites, mas mais flexíveis, e você pode gerenciar grupos grandes se necessário). Para usar, você precisa ter o projeto configurado no Firebase.

Depois, pode fazer upload das builds pelo site do Firebase ou até automatizar via CLI do Firebase ou Fastlane.

Muita gente integra no CI (Continuous Integration): a cada commit ou a cada versão, o CI gera o APK/IPA e já usa o Firebase CLI para distribuir para um grupo de testers – quando você vê, já chegou email “Nova versão disponível para teste” no seu celular. Isso acelera bastante o ciclo “desenvolver -> receber feedback”. Você também pode criar diferentes grupos de testers (e.g. QA interno, Beta testers externos) e enviar builds específicas para cada grupo facilmente.

Vale a pena?

Se você pretende ter um ciclo contínuo de testes, sim, muito. Por exemplo, em projetos profissionais, é comum toda semana (ou até todo dia) mandar uma versão para a equipe de QA verificar correções.

Fazer isso via TestFlight/Play Console repetidamente pode ser mais lento e burocrático. O Firebase App Distribution brilha nesses casos de distribuição interna contínua.

E nada impede de usar ele junto com as lojas: você pode primeiro mandar várias builds via Firebase para teste, e quando achar que está sólido, daí usar TestFlight/Play Console para um beta público ou lançamento final.

Contas de desenvolvedor(a) Apple e Google: por que preciso disso?

Antes de apertar aquele famoso botão “Publicar”, tem um passo essencial: criar suas contas de desenvolvedor(a) na Apple (para iOS) e na Google (para Android).

Pois é, diferente do mundo web onde você só precisa subir arquivos para um servidor, publicar um app nas lojas oficiais envolve um cadastro especial.

A Apple cobra uma taxa anual de $99 USD para você ser oficialmente um(a) desenvolvedor(a) iOS. Já a Google pede uma taxa única de $25 USD para a criação da sua conta na Play Store.

Essas taxas garantem acesso às ferramentas oficiais, permitem distribuir apps publicamente e dão direito ao suporte das próprias plataformas.

Outro detalhe importante: ambas as empresas analisam seu app antes dele ser publicado para todo mundo baixar.

A Apple é especialmente rigorosa, revisando não apenas questões técnicas, mas também conteúdo, experiência da pessoa usuária e conformidade com diretrizes bem específicas. O Google também revisa, mas costuma ser menos restritivo.

Por isso, esteja preparado para possíveis ajustes que precisarão ser feitos no seu app antes da aprovação final.

No começo, isso pode parecer burocracia demais, mas calma: depois que você configura tudo pela primeira vez, fica mais fácil nas próximas publicações. Encare esse processo como parte da jornada que vai garantir segurança, qualidade e confiança pro seu(sua) usuário(a) final.

Conclusão e próximos passos

Ufa, quanta coisa, hein? Vamos recapitular o cenário geral que vimos de forma amigável: após desenvolver seu app em React Native, você precisa gerar arquivos de build (APK/IPA) para poder distribuir.

Aprendeu que APK e IPA são como os executáveis do seu app para Android e iOS, respectivamente.

Viu que, com Expo, esse processo de build pode ser mais simples e automatizado, enquanto com React Native CLI você vai interagir com Gradle e Xcode para compilar e assinar seu app.

Aprendeu a importância de testar seu app em dispositivos reais e em modo release antes de mandar para a loja – afinal, melhor encontrar e corrigir bugs agora do que receber reviews ruins depois.

Na parte de distribuição, conversamos sobre o TestFlight para compartilhar betas no ecossistema Apple (permitindo até 10k testers externos!) e sobre os tracks de teste do Google Play (que te deixam distribuir para grupos controlados de usuários(as) no Android, de forma rápida e segura).

Por fim, conheceu o Firebase App Distribution como uma alternativa poderosa para gerenciar testes em múltiplas plataformas de forma ágil, obtendo feedbacks rápidos e dados de estabilidade em um só lugar.

A jornada de publicar um app envolve várias etapas e ferramentas, mas não se intimide! Este guia te deu uma visão do mapa geral – agora você sabe o que é o quê, e onde precisa aprofundar quando chegar em cada etapa.

Recomendo fortemente: quando for executar cada passo, consulte as documentações oficiais (React Native, Expo, Apple, Google, Firebase), pois elas trazem tutoriais atualizados e detalhados para te guiar.

Cada plataforma tem suas exigências e particularidades (certificados da Apple, políticas do Google Play, etc.), e seguir as guidelines vai evitar dor de cabeça.

No fim das contas, poucas coisas são tão gratificantes para um dev quanto ver aquele app em que você suou para codar finalmente disponível para outras pessoas baixarem e usarem.

Então, mãos à obra! Prepare seus builds, distribua para alguns testers legais, ajuste o que for preciso e, quando estiver pronto, clique no mágico botão de “Publicar”.

Você veio do mundo web, desbravou o universo mobile híbrido, e agora está prestes a lançar seu app para o mundo – conta comigo que vai dar tudo certo.

Bons códigos e boa publicação! Você está a um passo de levar sua criação do editor de código para os smartphones por aí.

Vai em frente, que o mundo dos apps te espera!