Como criar um app mobile com IA: do Expo às lojas

O jeito mais rápido de criar um app mobile com IA é pedir a um agente de código que monte um projeto React Native com Expo, testar cada mudança no seu próprio celular com o Expo Go e usar um backend hospedado como Supabase ou Firebase. O agente escreve as telas, a camada de dados e o login; você testa no aparelho, devolve os erros e cuida das etapas das lojas. Publicar ainda exige contas de desenvolvedor da Apple e do Google e passar pelos processos de revisão delas.

Este post percorre todo o caminho, de uma pasta vazia até as lojas: qual stack eu escolho e por quê, o primeiro prompt que dou ao agente, como testo no celular, login e notificações, publicação e onde os agentes mais tropeçam.

Primeiro, ajuste as expectativas

Existe uma diferença real entre fazer vibe coding de um site e de um app mobile. Na web, se o código roda, acabou. No mobile há uma camada de plataforma por cima do código: ferramentas de build, certificados de assinatura, permissões, regras das lojas. O agente dá conta da maior parte do código com tranquilidade; o lado da plataforma precisa dos seus olhos e das suas mãos.

A boa notícia: escolha as ferramentas certas e você não vai tocar na maior parte dessa camada nas primeiras semanas.

Qual stack: Expo, Flutter ou nativo

Há três caminhos principais.

Para iniciantes, minha resposta é clara: React Native + Expo. O motivo tem menos a ver com mérito técnico e mais com velocidade de feedback. O agente muda algo e você vê no celular segundos depois. Quanto mais curto esse ciclo, melhor funciona o vibe coding.

Flutter é uma boa escolha se você conhece Dart ou sua equipe já usa. Nativo só faz sentido quando há um motivo específico, como processamento de câmera, gráficos pesados ou integração profunda com a plataforma.

Passo 1: Configuração

O que você precisa:

• Node.js (uma versão LTS) e um gerenciador de pacotes
• Um agente de código: Claude Code, Codex, Gemini CLI ou outro agente de código
• Expo Go no celular, da App Store ou do Google Play
• Git, para que cada passo do agente possa ser desfeito

Crie o projeto você mesmo. Agentes que montam tudo do zero às vezes recorrem a templates desatualizados:

npx create-expo-app@latest habits
cd habits
git init && git add -A && git commit -m "initial scaffold"
npx expo start

Um QR code aparece no terminal. Escaneie com a câmera no iPhone ou de dentro do Expo Go no Android, e o app abre no seu celular. O computador e o celular precisam estar no mesmo Wi‑Fi. Se a rede atrapalhar, tente npx expo start --tunnel.

Passo 2: O primeiro prompt

O primeiro prompt molda todas as decisões que o agente toma depois. Deixe lacunas e ele as preenche com as próprias preferências. Eu escrevo algo assim:

This is an Expo (React Native, TypeScript) project. We're building a
simple habit tracker.

Screens:
1. Today: list of habits, each with a "done" button
2. Add: create a habit with a name and a daily goal
3. History: calendar view of the last 30 days

Rules:
- Use expo-router for navigation and follow the existing app/ folder.
- Keep data on the device for now (AsyncStorage). Backend comes later.
- Add packages with npx expo install, not npm install.
- Don't add native packages that don't run in Expo Go; ask first.
- Run npx tsc --noEmit after each step and fix the errors.
- When done, list the files you changed.

Duas linhas importam mais. npx expo install escolhe a versão do pacote compatível com o seu Expo SDK, e os agentes pulam isso o tempo todo. A regra de “nada de pacotes que não rodam no Expo Go” mantém você longe de builds nativos até realmente precisar deles.

Passo 3: Teste no celular e itere

Enquanto o npx expo start está rodando, o app recarrega no celular à medida que o agente edita os arquivos. O ciclo:

1. Experimente no celular e anote o que está errado.
2. Diga ao agente com precisão: “Na tela Add, o teclado cobre o botão de salvar, no iPhone.”
3. Se aparecer a tela vermelha de erro, copie o texto literalmente para o agente. Uma captura de tela também serve; a maioria dos agentes lê imagens.
4. Faça commit de cada passo que funciona.

Teste no iOS e no Android. O mesmo código se comporta de forma diferente: margens de safe area, tratamento do teclado, botão voltar, sombras. Com um celular só, use um emulador Android ou (num Mac) o iOS Simulator para a outra plataforma.

Passo 4: Backend com Supabase ou Firebase

Quando você quiser dados compartilhados entre aparelhos e contas de usuário, vai precisar de um backend. Não escreva seu próprio servidor; escolha um hospedado:

• Supabase: construído sobre PostgreSQL. Banco de dados, login, armazenamento de arquivos e atualizações em tempo real. Combina com quem conhece SQL ou quer aprender.
• Firebase: a plataforma do Google. Banco de documentos Firestore, login, mensagens. Bem integrado ao ecossistema mobile.

Peça ao agente para construir camada por camada, não tudo de uma vez:

We're moving to Supabase. For now, only do this:
1. Write a SQL file under supabase/migrations that creates habits and
   completions tables. Every row has a user_id.
2. Enable Row Level Security on both tables so a user can only read
   and write their own rows.
3. Don't change the app code yet. Show me the SQL; I'll apply it.

Não pule a parte do RLS. A chave do Supabase que vai dentro de um app mobile é pública por definição; o que protege seus dados são as regras no banco, não o segredo dessa chave. No Firebase, as security rules têm o mesmo papel.

Passo 5: Login

Login por e-mail é o mais simples; Supabase e Firebase oferecem os dois. Entrar com Google e Entrar com Apple exigem mais configuração: URIs de redirecionamento, um scheme do app e cadastro no console de cada plataforma.

Uma coisa para saber: pelas diretrizes da App Store, se o seu app oferece login social de terceiros, a Apple pode esperar também o Entrar com Apple ou uma opção equivalente focada em privacidade, com algumas exceções. Confira as regras atuais antes de enviar.

É assim que eu peço o login:

Add email + password sign-in with Supabase Auth.
- If there's no session, redirect to the sign-in screen.
- Store the session with expo-secure-store.
- Put a sign-out button on the Settings screen.
- Error messages should be clear and in plain English.
Don't add Google or Apple sign-in yet.

Passo 6: Notificações push

Notificações push consomem mais tempo do que qualquer outra coisa no mobile. No Expo, você começa com expo-notifications:

npx expo install expo-notifications expo-device

O que saber:

• Notificações locais (“me lembre todo dia às 21h”) não precisam de servidor e são de longe as mais fáceis. Para um app de hábitos, muitas vezes são tudo de que você precisa.
• Push remoto significa obter um push token, guardá-lo no seu servidor e enviar de lá. No iOS, isso exige uma conta Apple Developer e a capability de push.
• Teste o comportamento das notificações num aparelho real. O suporte a notificações no simulador e no Expo Go pode ser limitado e muda com o tempo.

Peça primeiro as notificações locais ao agente, veja funcionando e só então passe para o push remoto.

Passo 7: Builds e as lojas

O Expo Go serve para desenvolvimento; as lojas recebem um binário de app de verdade. O serviço em nuvem do Expo, o EAS, gera esse build para você:

npm install -g eas-cli
eas login
eas build:configure
eas build --platform android
eas build --platform ios

A grande vantagem dos builds na nuvem é não precisar configurar o Xcode e o Android SDK você mesmo. Dá até para gerar o build de iOS sem um Mac.

Apple:

• Assinatura anual paga do Apple Developer Program.
• Um registro do app no App Store Connect com capturas de tela, descrição, URL da política de privacidade e a declaração de dados do App Privacy.
• Distribua primeiro pelo TestFlight para você e alguns testadores, depois envie para revisão.
• Rejeições são normais. Motivos comuns: travamentos, texto de privacidade faltando, apps rasos que só “embrulham um site” e apps que deixam criar uma conta, mas não excluí-la.

Google:

• Um cadastro pago único no Google Play Console, mais verificação de identidade.
• Uma página na loja, o questionário de classificação de conteúdo e o formulário de Segurança dos dados.
• Contas pessoais de desenvolvedor novas podem ter que rodar um teste fechado com um número definido de testadores por um período definido antes de ir para produção; confira a regra atual no console.

O eas submit facilita enviar builds para as duas lojas, mas os formulários das lojas você mesmo preenche. Leia-os em vez de delegar ao agente; declarar quais dados seu app coleta é responsabilidade sua.

Onde os agentes sofrem

Esta é a lista dos lugares onde mais perdi tempo fazendo vibe coding de apps mobile.

Erros de build nativo

Gradle, CocoaPods, versões do Xcode, níveis do Android SDK. Esses erros são longos, ruidosos e específicos do ambiente. O agente não enxerga o Xcode da sua máquina; ele chuta. O que ajuda:

• Cole a saída completa do erro, não as primeiras linhas. A causa real muitas vezes está perto do fim ou enterrada no meio.
• Use o EAS Build quando puder; o ambiente fica fixo.
• Não deixe o agente editar à mão as pastas ios/ e android/. No Expo elas costumam ser geradas a partir da configuração, então mudanças duradouras vão no app.json ou num config plugin.

Assinatura e certificados

Certificados, provisioning profiles e bundle identifiers no iOS; uma keystore no Android. Aqui os agentes podem dar instruções confiantes, mas erradas. Deixar o EAS gerenciar as credenciais é o caminho mais tranquilo. Se você perder sua upload key do Android, publicar atualizações do mesmo app vira uma dor de cabeça séria, então faça backup.

Versões incompatíveis

O agente usa a API de um pacote da época em que foi treinado; seu projeto pode ter outra versão. npx expo install --check lista os pacotes incompatíveis. Dizer ao agente “confira primeiro a versão no package.json e escreva com base na documentação dessa versão” ajuda.

Testar em uma plataforma só

O agente escreve um layout que funciona no iOS e transborda no Android. Veja cada funcionalidade nas duas.

Pedir tudo de uma vez

“Adicione login, notificações e pagamentos” deixa os três pela metade. Uma funcionalidade por vez, com commit entre elas.

Segurança importa ainda mais no mobile

Tudo o que você coloca num app mobile acaba no aparelho do usuário, onde pode ser desempacotado e lido. Então:

• Nunca coloque segredos no bundle do app. No Expo, variáveis de ambiente que começam com EXPO_PUBLIC_ são embutidas no bundle, o que as torna públicas. A chave service_role do Supabase, a chave secreta de um provedor de pagamento ou uma chave de API de IA nunca podem ir no app; elas ficam no lado do servidor, por exemplo numa edge function.
• Guarde segredos num arquivo .env e confira se o .env está no .gitignore.
• Não cole chaves de API no chat. Diga ao agente qual variável de ambiente ler, não a chave em si.
• Teste as regras do banco. Entre com uma segunda conta e veja se consegue ler os dados da primeira.
• Leia os comandos que o agente roda, principalmente eas, git push, exclusões e comandos de banco, antes de aprovar.

Fazendo isso com o AgentVera

Dá para fazer tudo isso num terminal comum. Em projetos mobile, eu gosto de rodar vários agentes lado a lado, e faço isso no AgentVera:

• Agentes separados em worktrees separados. Por exemplo, o Claude Code trabalha no schema do Supabase e nas edge functions num git worktree enquanto o Codex constrói telas em outro. O painel Git mostra as mudanças de cada branch.
• Um terminal na grade. O npx expo start fica aberto num painel para você ver a saída do Metro ao lado dos agentes; é para isso que serve o painel de editor e terminal.
• Revisão antes do merge. O code review automático faz um segundo modelo checar cada turno do agente; mesmo assim, leia o diff você mesmo.
• O banco de dados. Adicione a conexão Postgres do Supabase ao gerenciador de banco de dados para conferir as tabelas e linhas que o agente criou.
• Acompanhamento de tokens. Logs de build longos incham o contexto rápido; o uso de tokens fica visível por painel.

O AgentVera não gera o build para o seu celular nem envia para as lojas; essa parte continua com o Expo e os consoles das lojas.

Checklist rápido

• Projeto Expo criado por você, primeiro commit no git
• Primeiro prompt lista telas, regras e a exigência do npx expo install
• Cada funcionalidade testada no celular, nas duas plataformas
• RLS no Supabase ou security rules no Firebase ativados e testados
• Nenhuma chave secreta no bundle do app
• Keystore do Android com backup
• Política de privacidade e declarações de dados das lojas prontas

Concluindo

Criar um app mobile com IA hoje é um objetivo realista, mas não termina em “me escreva um app”. Comece com o Expo, acompanhe cada mudança no celular com o Expo Go, use um backend hospedado, adicione funcionalidades uma por vez e assuma você mesmo as etapas de plataforma: assinatura, formulários das lojas, revisão. Para conferir o que o agente escreveu, veja code review com IA; para rodar agentes em paralelo, veja git worktrees para agentes em paralelo.