Por que vibecoding não funciona pra app mobile (e o que fazer com seu protótipo do v0)

Resposta direta, antes do post: vibecoding não entrega app mobile de produção porque as ferramentas não geram o que a loja exige. O v0 da Vercel gera site React/Next.js — não gera React Native (Vercel Community, 2026). O Bolt gera React Native via Expo, mas roda num sandbox de navegador que não tem Xcode, Android Studio nem o pipeline de build da Expo (Bolt Help Center, 2026). Resultado: você sai do v0 com um PWA disfarçado que a Apple rejeita por ser "site reempacotado", ou sai do Bolt com código que não vira .ipa nem .apk. O protótipo é ótimo. Ele só não é um app. Trate ele como wireframe interativo e refaça a versão de produção em Flutter ou nativo.

Eu construí dois apps mobile sozinho, do zero à loja: o OverAir (memória digital via WhatsApp, 0 pagantes hoje — vou falar disso aberto) e o Studio Kallos (agendamento pra estúdios de beleza). Os dois são Flutter, rodando em produção na App Store e na Play Store. Eu sei exatamente onde o vibecoding mobile para, porque já fiz à mão tudo que ele não faz.

Esse post é a régua. Onde v0/Bolt/Lovable param. Por que param. E o que fazer com o protótipo que você já tem.

O que cada ferramenta realmente gera

A primeira confusão é achar que "gerou tela bonita no celular" significa "gerou app". Não significa. Olha o que cada uma produz de verdade em 2026:

Ferramenta	Saída real	Vira app de loja?
v0 (Vercel)	Next.js + React + Tailwind. Site web.	Não. É site. Empacotado em WebView, a Apple rejeita.
Bolt.new	React Native via Expo	Código sim, build não — roda em sandbox de navegador, sem Xcode/EAS (Bolt, 2026)
Lovable	React web + Supabase	Não. É web app. Mesmo destino do v0.

O v0 é honesto sobre isso, inclusive. A própria Vercel construiu o app iOS do v0 em React Native com Expo — e contou que migrou a lógica de negócio do cliente pro servidor justamente porque o app nativo é uma casca fina sobre a API (Vercel Engineering, 2026). Ou seja: nem a Vercel usa o v0 pra gerar o próprio app nativo. Ela usou engenheiros React Native.

O Bolt chegou mais perto — gera Expo de verdade. Mas tem uma frase no próprio suporte que mata a ilusão: o código roda "num sandbox de navegador que não consegue rodar Xcode, Android Studio ou o pipeline de build da Expo" (Bolt Help Center, 2026). Você tem o código. Não tem a fábrica que transforma código em binário assinado. E a fábrica é a parte difícil.

O muro da Apple: Guideline 4.2

Se você empacota o protótipo do v0 (que é site) dentro de uma WebView e manda pra App Store, esbarra na Guideline 4.2 — Minimum Functionality. O texto oficial da Apple é direto:

"Seu app deve incluir features, conteúdo e UI que o elevem acima de um site reempacotado. (...) apps não devem ser primariamente material de marketing, propaganda, recortes de web (web clippings), agregadores de conteúdo ou coleção de links." — App Store Review Guidelines 4.2

"Web clipping" é o termo da Apple pra exatamente isso: um site dentro de uma WebView. PWA embrulhado em casca nativa cai nessa regra com frequência. A Apple não te dá um número público de rejeição, então não vou inventar um — mas a resposta padrão do revisor é conhecida: "seu app não é suficientemente diferente de navegar no site pelo navegador". Eu não arriscaria a fila de review (que em 2026 ainda leva de horas a dias) num app que tem 50% de chance de voltar com 4.2. Esse é o jeito errado de gastar a janela de lançamento.

Os 5 nativos que o protótipo nunca monta

Tela bonita é o que o vibecoding faz bem. O problema é tudo que tá embaixo da tela. Aqui estão os cinco que eu tive que montar à mão no OverAir e no Kallos — e que nenhum prompt entrega pronto:

1. Push notification de verdade

No OverAir, o push é o produto — é assim que a memória te lembra de coisas. Pra isso funcionar eu precisei de firebase_messaging, registro de token APNs no lado iOS, certificado de push no portal da Apple, e o canal de notificação no Android. Um protótipo v0 manda notificação? Manda — notificação do navegador, que no iOS depende do Safari estar aberto e que ninguém vê. Não é a mesma coisa. Push nativo exige APNs e FCM configurados no binário. O prompt não toca nisso.

2. Biometria e permissões nativas

Câmera, microfone, Face ID, localização — cada uma exige uma string de justificativa no Info.plist (iOS) e uma permissão declarada no AndroidManifest.xml. Esquece a string do Info.plist e o app crasha na hora que pede a câmera, ou volta da review reprovado. No Kallos eu uso image_picker pra foto de cliente e permission_handler pra orquestrar o fluxo de permissão. Isso é arquivo de configuração nativo, não JSX. Vibe-coder não escreve Info.plist.

3. Deep link / universal link

Quando o cliente do Kallos clica num link de agendamento, o app abre na tela certa. Isso é app_links no Flutter + um arquivo apple-app-site-association hospedado no domínio + o assetlinks.json do Android, com verificação de assinatura. É chato, é nativo, e é invisível — até faltar, e aí o link abre o navegador em vez do app. Nenhuma ferramenta de vibecoding monta os arquivos de associação de domínio pra você.

4. Splash, ícone adaptativo e atalhos

Esse é o que separa "app de verdade" de "protótipo". Splash screen nativa (não aquela tela branca de 2 segundos), ícone adaptativo que se ajusta ao formato do launcher Android, atalhos de toque longo no ícone. No Kallos eu gero isso com flutter_launcher_icons. Sem isso, o app parece amador na primeira tela — e a primeira impressão na loja é a tela de ícone. Vibe-coder ignora 100% disso.

5. Estado offline e sincronização

App mobile abre no metrô, no elevador, no 3G ruim. Tem que funcionar offline e sincronizar depois. Protótipo web assume conexão sempre. Reescrever pra offline-first não é ajuste — é decisão de arquitetura que você toma no início.

O custo escondido: assinatura, provisioning e as lojas

Mesmo que você tivesse o código React Native perfeito do Bolt, ainda falta a parte que custa dinheiro e tempo: transformar código em binário que entra na loja. Isso ninguém faz vibe-codando.

Item	O que é	Custo / fricção
Apple Developer Program	Conta obrigatória pra publicar iOS	US$ 99/ano (Expo Docs, 2026)
Google Play Developer	Conta obrigatória pra publicar Android	US$ 25, taxa única (Expo Docs, 2026)
Distribution certificate + provisioning profile	Assinatura criptográfica do binário iOS	Gerados via EAS ou Xcode; exigem conta Apple com permissão de credenciais (Expo App Signing, 2026)
TestFlight / Play internal track	Distribuição de teste antes da loja	Configuração de tester, build assinado, processamento
Review	Fila de aprovação Apple/Google	Horas a dias, com risco de 4.2

Code signing é o ponto onde a maioria dos founders que vêm de vibecoding empaca. Não é um conceito de produto — é criptografia de cadeia de confiança entre você, a Apple e o dispositivo. A própria Expo, que automatiza isso melhor que ninguém, ainda exige que você tenha uma conta Apple com permissão pra criar certificados, identifiers e provisioning profiles (Expo, 2026). A ferramenta de vibecoding nem chega nessa porta.

Hot reload: o número que muda o dia a dia

Tem um argumento de produtividade que ninguém te conta no hype. Quando você desenvolve mobile de verdade, você roda o app no simulador e edita o tempo todo. A velocidade desse ciclo define quantas iterações você faz por hora.

Hot reload do Flutter: 0,4 a 0,8 segundo, preservando o estado do app (Flutter Docs, 2026). Você muda uma cor, salva, e em meio segundo a tela atualizou sem perder onde você estava no fluxo. O Fast Refresh do React Native melhorou com a New Architecture, mas mudanças que tocam módulo nativo ainda forçam rebuild completo (Flutter vs React Native, 2026) — e rebuild completo é dezenas de segundos.

Na minha experiência montando o OverAir e o Kallos, a diferença prática entre meio segundo e um rebuild de 30 segundos é brutal — fácil 30x mais iterações por hora quando o ciclo é sub-segundo. Não é número de benchmark, é número de dia de trabalho. Em quem programa 6 horas de UI, isso é a diferença entre testar 400 variações e testar 12.

O que fazer com seu protótipo do v0

Aqui é onde eu mudo de "não funciona" pra "use direito". O protótipo do v0/Bolt/Lovable tem valor — só não é o valor que te venderam. Use assim:

Trate como wireframe interativo de alta fidelidade. Ele resolveu seu design, seu fluxo de telas, sua copy, sua paleta. Isso é trabalho real e economiza dias de Figma. Mostra pra investidor, valida com usuário, fecha o escopo.
Extraia as decisões, não o código. Anote: quais telas, qual navegação, quais estados de UI. Esse é o briefing pra versão de produção.
Refaça a camada nativa em Flutter (minha escolha) ou React Native com time que sabe Expo de verdade. Flutter porque um codebase entrega iOS + Android, o hot reload é sub-segundo, e a stack toda — push, deep link, permissões, splash, offline — tem pacote maduro.
Não tente "exportar e consertar" o código vibe-coded. Eu já fiz a conta: destrinchar React do v0 pra forçar virar React Native dá mais trabalho que reconstruir limpo. O protótipo assumiu web em cada decisão de arquitetura. Migrar essas suposições uma a uma é mais caro que recomeçar com a base certa.

Veredito

Vibecoding é uma máquina de protótipo excelente e uma fábrica de app mobile inexistente. Pra landing page, dashboard interno, MVP web que valida ideia — manda ver, o v0 e o Lovable economizam semanas. Pra app que entra na App Store e na Play Store, eu evitaria começar pelo vibecoding, porque a parte fácil (a tela) é a única que ele faz, e a parte difícil (nativo + assinatura + review) é 100% manual de qualquer jeito.

Se você tem um protótipo do v0 e quer transformar em app de produção, o caminho honesto é: protótipo vira spec, Flutter vira produto. Foi assim que o OverAir e o Kallos saíram do papel pra loja. É o trabalho que a Hens faz — pegar a ideia validada e entregar o binário assinado que passa na review.