Expo Managed, Prebuild e Bare: quando usar cada um
A diferença prática entre managed, prebuild e bare no Expo, e quando cada fluxo deixa de valer a pena.
O Expo resolve muita coisa no começo de um app React Native: build, updates, permissões e uma boa parte das APIs nativas. O problema aparece quando o projeto pede um SDK que o managed não cobre, ou quando o time precisa mexer em código nativo de verdade.
Este texto separa os três caminhos mais comuns.
Managed
No fluxo managed você quase não abre o Xcode ou o Android Studio. O EAS Build gera o binário, e o app.json / app.config.ts descreve o app.
Funciona bem quando:
- O app usa só módulos do Expo ou bibliotecas com config plugin
- Você quer testar no Expo Go no início
- O time é pequeno e não quer manter pasta
ios/eandroid/no git
O limite aparece rápido: SDK sem plugin, permissão customizada, ou um cliente nativo de marketing (como o Klaviyo) costuma exigir código nativo.
Prebuild (o meio-termo)
npx expo prebuild gera as pastas nativas a partir da config. Você continua no ecossistema Expo, mas passa a ter projeto iOS e Android reais.
Use prebuild quando:
- Precisa de um módulo nativo pontual
- Quer plugins e ainda assim commitar (ou gerar) o código nativo
- O app já não cabe no Expo Go
O cuidado: se você editar ios/ e android/ na mão e rodar prebuild de novo, as mudanças podem ser sobrescritas. Prefira config plugins sempre que der.
Bare
Bare é um app React Native clássico, com ou sem pedaços do Expo. Você instala o que quiser no Podfile e no Gradle.
Faz sentido quando:
- Há bastante código nativo próprio
- O app já nasceu com CLI e não vale migrar
- Ferramentas de push, analytics ou pagamentos exigem setup nativo pesado
Como eu escolho
- Começo managed se o app é simples.
- Subo para prebuild no primeiro módulo nativo.
- Só vou para bare se o prebuild vira briga toda semana.
Se o time já usa Expo e só precisa de um SDK, prebuild costuma ser o menor custo. Bare é o destino de apps com camada nativa grande, não o ponto de partida.