O Lovable faz aplicativo mobile? A resposta da documentação — e os quatro caminhos reais

Boa parte da frustração nessa busca vem de três coisas diferentes atendendo pelo mesmo nome.

App web: roda no navegador. É o que o Lovable produz, e é excelente para isso.

Web no celular: o mesmo app web, com layout que funciona bem numa tela pequena. O Lovable faz isso bem — e para muitos produtos é a resposta inteira.

App de celular: um programa instalado, distribuído pelas lojas, que fala direto com o aparelho — notificações push, uso offline, câmera e sensores, widgets, relógio, pagamentos das lojas. É o que as pessoas querem dizer quando perguntam "e o app?", e é o que um app web não vira só por ganhar um ícone.

O teste de dez segundos: os seus usuários chegam clicando num link ou abrindo um ícone? Se é o link, você provavelmente não precisa migrar nada.

"Quero que funcione bem no celular." Fique no Lovable. Ajuste o layout. Pronto.

"Quero um ícone na tela inicial." PWA — a documentação do Lovable descreve o caminho. Sem loja, sem revisão da Apple, sem código novo.

"Quero estar nas lojas." Aqui começa a decisão de verdade, porque estar na loja exige um pacote instalável — e há um jeito barato e arriscado, e jeitos que reconstroem a frente.

"Quero notificações, offline, câmera, a sensação de app de verdade." Isso só um app nativo (ou multiplataforma real) entrega. Um site embrulhado não.

"Investidores ou clientes esperam um app de verdade." Legítimo — presença na loja é sinal de credibilidade em muitos mercados. Mas pese o custo contínuo: um app é uma segunda superfície de produto para manter, não uma caixa a marcar. Se você ainda está validando a ideia, o protótipo web no Lovable costuma ser a ferramenta certa, e o app é o que vem depois.

Este é o modelo mental que faz todos os caminhos fazerem sentido. Um app do Lovable tem duas metades:

O backend — você mantém. Apps do Lovable costumam usar o Supabase (a documentação deles lista o Supabase como backend): o seu banco de dados, os seus usuários e o login deles, os arquivos, a lógica da API. Nada disso é específico da web. O Supabase publica bibliotecas oficiais para Swift e Kotlin além de JavaScript — o que significa que um app de celular, de qualquer ferramenta, pode falar com o mesmo backend que o seu app web usa hoje. Os seus dados não migram para lugar nenhum; eles ficam onde estão e ganham um segundo cliente.

A frente — você reconstrói. A interface que o Lovable gerou é escrita em tecnologia web, e os celulares não rodam isso nativamente. É a parte que cada caminho abaixo trata de um jeito: embrulhar, re-renderizar ou reconstruir nativo.

É também por isso que exportar o código do Lovable (a documentação descreve a sincronização com o GitHub, disponível em todos os planos) não resolve o problema sozinho: o que sai é o projeto web. Útil — muito — como a especificação do que reconstruir: as suas telas, os fluxos, a lógica, prontos para entregar a um agente. Mas não é algo que um celular executa.

Um aviso antes dos caminhos: a opção "em cinco minutos" que você vai ver anunciada — embrulhar o site numa casca de WebView — esbarra nas diretrizes de revisão da Apple, que estabelecem um mínimo de funcionalidade abaixo do qual sites reembalados são uma categoria conhecida de rejeição. Barato tem motivo.

Caminho 1 — continuar web, virar PWA. Nenhum código novo. Ícone na tela inicial, sem presença nas lojas, recursos limitados ao navegador. Certo quando o objetivo era "ícone", não "app". Custo: o seu tempo no Lovable.

Caminho 2 — casca (WebView). O seu app web dentro de uma casca nativa fina, enviada às lojas — Capacitor, ou TWA no Android, como a documentação do Lovable sugere. Rápido e barato — e frágil: herda todas as limitações do navegador, parece um site numa moldura porque é um, e cascas finas são uma categoria conhecida de rejeição na revisão da Apple. Defensável quando a presença na loja é exigência formal e o produto é feito de conteúdo.

Caminho 3 — reconstruir multiplataforma (React Native). Um app de verdade em JavaScript, um código para as duas lojas, falando com o seu Supabase atual. A sua frente do Lovable vira a especificação; várias ferramentas com IA — Rork, Vibecode, RapidNative — geram esse tipo de projeto, em geral cobradas em créditos. Certo quando uma equipe de JavaScript vai ser dona do código.

Caminho 4 — reconstruir nativo (SwiftUI + Kotlin/Compose). A versão de convicção total: interface nativa em cada plataforma, os recursos do aparelho desde o primeiro dia, a sensação pela qual apps instalados são julgados. Historicamente o caminho caro — a coisa que os agentes de IA mudaram. A Modaal (nossa) constrói SwiftUI nativo para iPhone e Kotlin com Compose nativo para Android a partir de um projeto: o seu agente lê o projeto exportado do Lovable e o esquema do seu Supabase como especificação e reconstrói a frente contra o backend que você já roda — com um plano que você aprova antes de cada funcionalidade. Sem créditos: ele usa a assinatura de IA que você já paga, com prompts ilimitados. O plano gratuito inclui um projeto ativo e uma plataforma à sua escolha; o Pro custa 9 € por mês na cobrança anual (15 € mensal) e liga as duas plataformas e a distribuição nas lojas — detalhes em /pricing. É preciso um Mac. Como um agente constrói na prática e o que é vibe coding estão nos artigos ao lado.

1. Dê nome ao objetivo usando a seção acima. Se era "funcionar no celular" ou "ícone na tela inicial", pare aqui — você terminou sem migrar nada.

2. Faça o inventário do que fica. Liste as tabelas do Supabase, a configuração de login, os arquivos, as funções. Esse inventário é a fundação da migração — e a prova de que a maior parte do seu produto sobrevive intacta.

3. Exporte a especificação. Sincronize o projeto do Lovable com o GitHub. O código web não é o seu app de celular, mas é a descrição completa e precisa do que o app faz — telas, fluxos, estados —, que é exatamente o que um agente de IA constrói bem.

4. Escolha o stack — multiplataforma ou nativo. Essa única escolha define a ferramenta. Quanto custa e o caminho Android do zero à Play Store ajudam a decidir.

5. Reconstrua a frente contra o backend ao vivo. Aponte o app novo para o mesmo projeto do Supabase que o app web usa. Publique no TestFlight, depois nas lojas. O seu app web continua rodando o tempo todo — esta migração não tem parada, porque nada sai do lugar.