Expo Go ou development build: qual usar?

Expo Go é um aplicativo pronto que executa projetos compatíveis com os módulos já incluídos nele. Uma development build é uma versão do seu próprio app com as bibliotecas nativas de que o projeto precisa e ferramentas de desenvolvimento. Comece com Expo Go para explorar; migre para development build quando o produto precisar de código nativo, configuração própria ou testes mais fiéis.

Esta decisão fica mais clara depois da base de React Native e do guia de Expo. Aqui a gente monta um critério técnico, não uma torcida por uma das opções.

Cozinha compartilhada ou oficina do seu produto

Imagine uma cozinha compartilhada já equipada. Você chega e cozinha com os fornos e utensílios disponíveis: é rápido, mas não pode instalar um exaustor novo. Expo Go ocupa esse papel. Ele já contém um conjunto definido de módulos nativos e consegue carregar seu JavaScript sem você compilar outro aplicativo.

Uma development build é como a oficina montada para o seu produto. Você escolhe ferramentas, permissões, identificadores e código nativo; depois compila um aplicativo de desenvolvimento que se conecta ao servidor Metro. O pacote expo-dev-client adiciona um launcher e uma interface de diagnóstico a essa build.

O limite da analogia: os dois fluxos ainda executam o mesmo projeto Expo e podem usar Fast Refresh. Tecnicamente, a diferença decisiva está no binário nativo. Se mudar JavaScript, Metro atualiza; se instalar ou configurar código nativo, você precisa gerar outra development build.

Comece com a matriz correta em agosto de 2026

Para um projeto novo no SDK estável atual, gere explicitamente SDK 57:

npx create-expo-app@latest meu-app --template default@sdk-57
cd meu-app
npx expo-doctor@latest

O SDK 57 combina Expo 57, React Native 0.86 e React 19.2. Essa matriz é mais importante que instalar separadamente o React Native mais novo. O projeto de prova desta série retornou:

Existe uma transição específica nesta data: as versões públicas de Expo Go nas lojas ainda acompanham SDK 54 enquanto a atualização do SDK 57 passa pela aprovação das lojas. Para SDK 57, a documentação orienta obter a versão adequada pelas ferramentas Expo em Android e simuladores, ou preferir development build. Não rebaixe um produto para SDK 54 apenas para evitar entender a matriz; escolha de acordo com o dispositivo e a fase do trabalho.

Faça uma pergunta simples antes de escolher

Liste o que o app usa:

Só módulos presentes no Expo Go?        -> Expo Go pode atender ao aprendizado.
Biblioteca com código Android/iOS?       -> Development build.
Config plugin ou permissão nativa nova?  -> Development build e recompilação.
Push, deep link ou credencial real?      -> Development build recomendada.
Teste próximo do binário de produção?    -> Development build.

Expo Go é um ambiente de aprendizado e prototipagem. Ele não é uma representação personalizada do binário que você publicará. Development build reduz essa distância porque contém seu identificador, seus módulos e sua configuração nativa, embora ainda traga ferramentas de desenvolvimento.

Instale o cliente de desenvolvimento

Dentro do projeto SDK 57, use o resolvedor do Expo:

npx expo install expo-dev-client
npx expo install --check

No teste local, foi selecionado expo-dev-client@57.0.14, e a conferência respondeu Dependencies are up to date. O comando altera dependências JavaScript, mas sozinho não cria um aplicativo instalável.

O package.json passa a conter uma dependência parecida com esta:

{
  "dependencies": {
    "expo": "~57.0.15",
    "expo-dev-client": "~57.0.14",
    "react-native": "0.86.2"
  }
}

Não copie números antigos de outro tutorial. Use npx expo install para deixar o SDK escolher a faixa compatível e confira o resultado no arquivo.

Escolha entre compilação local e EAS Build

Se a máquina tem Android Studio ou Xcode configurado, você pode criar e instalar localmente:

npx expo run:android
# ou, no macOS com Xcode:
npx expo run:ios

Esses comandos geram os diretórios nativos quando necessário, compilam e tentam instalar no destino. São operações bem diferentes de npx expo start: o start serve JavaScript; o run constrói um binário nativo.

Com EAS Build, o perfil típico começa em eas.json:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    }
  }
}

Depois de autenticar e configurar o projeto, o comando remoto é:

npx eas-cli@latest build --profile development --platform android

Esta aula não marca o código como totalmente testado porque a compilação nativa e o build remoto não foram executados no ambiente editorial. Eles exigem SDKs locais ou conta Expo, credenciais e infraestrutura externa. O que foi testado foi a instalação compatível, o prebuild isolado e o bundle JavaScript.

Inicie o Metro para a development build

Depois de instalar o aplicativo compilado no dispositivo, inicie o servidor:

npx expo start --dev-client

O cliente encontra o projeto pela rede ou por um QR code compatível. Se celular e computador não se enxergam na mesma rede, tente o modo túnel apenas depois de confirmar firewall e conexão:

npx expo start --dev-client --tunnel

Túnel pode ser mais lento e depende de serviço externo. Não é correção para qualquer tela em branco. Leia o terminal, confirme que o binário corresponde ao SDK e veja se o app está tentando abrir o mesmo projeto.

Reconheça o erro de binário desatualizado

Suponha que você instale uma biblioteca com código nativo e apenas reinicie o Metro. O JavaScript consegue importar o nome, mas o binário antigo não contém o módulo. A família de erro costuma indicar que o módulo nativo não foi encontrado:

Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ModuloExemplo' could not be found. Verify that a module by this name
is registered in the native binary.

Na cozinha compartilhada, você incluiu no cardápio um equipamento que não está instalado. Voltando à técnica, reinstale dependências de modo compatível, gere a configuração nativa e recompile a development build:

npx expo install pacote-com-codigo-nativo
npx expo prebuild --clean
npx expo run:android

prebuild --clean recria diretórios nativos e pode apagar ajustes manuais. Trate configuração persistente em app.json, app.config.ts ou config plugins, assunto da lição de config plugins e prebuild.

Separe três ciclos de mudança

Uma regra prática evita recompilações inúteis:

Mudou texto, lógica, estilo ou imagem?    Reinicie/atualize o Metro.
Mudou módulo ou configuração nativa?      Recompile a development build.
Mudou só credencial do servidor remoto?   Revise ambiente; talvez sem rebuild.

As fronteiras podem variar: algumas variáveis entram no bundle durante a compilação, e algumas configurações geram alterações nativas. Consulte a documentação do módulo em vez de decidir apenas pelo nome do arquivo.

Missão: documente a escolha do seu app

Escolha uma biblioteca que você pretende usar e responda: ela funciona no Expo Go? Tem config plugin? Adiciona permissões? Exige rebuild depois de instalar? Registre a fonte oficial ao lado da resposta.

Decisão: Expo Go | development build
Módulo avaliado:
Código nativo:
Config plugin:
Quando recompilar:
Fonte oficial:

O exercício está pronto quando outra pessoa entende sua decisão sem testar no escuro. Em seguida, organize as telas dessa build com o sistema de arquivos na lição de Expo Router.