Bubble no-code: o que muda quando o app vai para a App Store e o Google Play

Quase todo texto em português sobre o Bubble repete a mesma frase quando chega ao celular: "ele faz web app; para ir à loja, use um empacotador". Essa frase envelheceu. A própria plataforma passou a gerar app nativo e a publicá-lo nas lojas da Apple e do Google, e isso muda a decisão de quem pensa em lançar um aplicativo sem time de desenvolvimento.

Muda também a conta. Ir para a loja traz custos e regras que não aparecem na assinatura: limite de builds por mês, contas de desenvolvedor à parte, revisão da Apple e do Google a cada função nova. A seguir, o que é o Bubble, como ele funciona, o que cada plano permite no app nativo e um critério para decidir se o seu projeto precisa mesmo estar na loja.

O que é o Bubble no-code?

O Bubble é uma plataforma no-code para construir aplicações completas por interface visual. As telas se montam arrastando elementos, o banco de dados se define por campos e tipos, e a lógica se descreve em workflows, sequências do tipo "quando o usuário clicar aqui, crie este registro e envie aquele e-mail".

A diferença para um construtor de sites é que o resultado não é uma vitrine: é um sistema com login, cadastro, regras de negócio e integrações. Por isso ele aparece com frequência em três situações: o produto digital de quem quer validar uma ideia antes de contratar desenvolvimento, a ferramenta interna de uma equipe e o portal de clientes de uma empresa de serviço.

Um ponto que pesa na decisão desde o primeiro dia: a aplicação existe dentro da plataforma. Segundo a central de suporte do Bubble, não há como exportar a aplicação como código; os dados saem em CSV ou por API, e quem decide sair recebe um arquivo com a lógica e o desenho para acelerar a reconstrução em outro lugar (Bubble, "Can I export my data from the Bubble platform?").

Como funciona o Bubble por dentro?

Todo projeto no Bubble tem quatro camadas que trabalham juntas: a interface (o que o usuário vê), o banco de dados (o que fica guardado), os workflows (o que acontece quando alguém age ou quando um agendamento dispara) e as integrações. Para estas, o recurso central é o API Connector, que, nas palavras da documentação, permite conectar o app "a quase qualquer API externa".

Desde que o mobile nativo entrou na plataforma, um mesmo projeto pode abrigar um web app, um app nativo ou os dois. Eles compartilham backend, banco de dados, workflows e conexões com APIs. É prático, porque a regra de negócio é escrita uma vez só, e é também o motivo de um detalhe de custo que trataremos adiante: o processamento dos dois se soma.

A cobrança do Bubble não é por usuário, e sim por unidade de processamento consumida. Esse modelo, e o que ele faz com a fatura quando o produto cresce, está explicado em detalhe no nosso artigo sobre a conta das ferramentas no-code que chega depois que o app funciona. Aqui o foco é outro: o que muda quando o app sai do navegador e vai para a loja.

O Bubble cria app para celular de verdade?

Sim, e por dois caminhos diferentes, que convém não confundir. O primeiro é o web app responsivo: a mesma aplicação, aberta no navegador do celular. O segundo é o app nativo, que a página de preços do Bubble descreve assim: os apps nativos "rodam em React Native" e "podem ser publicados nas lojas de iOS e Android".

Bubble, página de preços e artigo de suporte sobre publicação nas lojas; Apple Developer e Google Play Console (consultados em 12/10/2026)

A diferença prática não está na tela, que pode ficar parecida nos dois casos. Está no processo de publicação. No web app, a sua equipe publica e o usuário vê. No app nativo, entre a sua equipe e o usuário existe uma loja com regras próprias, e é aí que aparecem os custos que a assinatura não mostra.

O que o plano gratuito do Bubble deixa fazer no app nativo?

O plano Free serve para construir e testar, não para lançar. Segundo a página de preços, ele inclui o editor de mobile nativo, o depurador mobile e o teste no próprio aparelho, mas não inclui versão ao vivo. E a versão ao vivo é o que a loja recebe: sem ela, não há o que enviar à Apple ou ao Google.

Isso é útil para uma decisão concreta. Dá para montar o protótipo inteiro, testar no celular da equipe e mostrar a clientes de confiança sem pagar a plataforma. A conta começa no momento em que alguém decide publicar. Vale planejar o cronograma com essa virada em mente, e não descobrir na véspera do lançamento que o plano precisa mudar.

Quantos builds e versões cada plano do Bubble permite?

Este é o ponto que quase nenhum comparativo traz, e é o que mais pesa para quem vai manter um app na loja. Cada plano pago limita quantos builds você pode enviar às lojas por mês e quantas versões do app podem estar ao vivo.

Cinco builds por mês parecem muito até a primeira semana de lançamento. Um build pode ser recusado pela loja, um teste interno pode revelar um erro que pede outro envio, e iOS e Android costumam caminhar em paralelo. Quem conta com uma rotina de correções frequentes deve ler esse número como teto de iterações, não como folga.

As versões ao vivo respondem a outra pergunta: quantas versões diferentes do app podem estar rodando ao mesmo tempo. Isso pesa porque nem todo usuário atualiza o aplicativo no dia em que a loja libera a versão nova.

Quanto custa colocar o app do Bubble nas lojas, além da assinatura?

A publicação não sai em nome do Bubble: sai em nome da sua empresa. Por isso, o artigo de suporte da plataforma lista como pré-requisito ter contas de desenvolvedor próprias, e deixa claro que o Bubble publica apenas na Apple App Store e na Google Play Store, sem suporte a lojas Android alternativas (Bubble, "Publishing your Bubble app to iOS App Store and Google Play").

• Apple: o Apple Developer Program custa US$ 99 por ano, cobrado em moeda local onde houver. Empresas precisam ser pessoa jurídica e ter número D-U-N-S, que a Apple diz ser gratuito na maioria dos países (Apple Developer, enrollment).
• Google: a conta no Google Play Console tem taxa única de US$ 25, com verificação de identidade e cartão no nome legal do titular.
• Conta pessoal nova no Google: contas pessoais criadas depois de 13 de novembro de 2023 precisam rodar um teste fechado com pelo menos 12 testadores por 14 dias seguidos antes de liberar o app na loja (Google Play Console Help).
• Material de loja: ícones, tela de abertura, capturas de tela e uma política de privacidade publicada. Segundo o Bubble, a falta da política de privacidade é motivo de recusa nas duas lojas.

Some isso ao cronograma, não só ao orçamento. A conta da Apple para empresa depende de validação de dados cadastrais; a conta pessoal nova do Google depende de duas semanas de teste com gente de verdade. Nenhum desses prazos é controlado pelo Bubble, e nenhum deles aparece na tela de preços.

Atualização OTA ou build novo: o que passa pela revisão da loja?

Depois que o app está publicado, cada mudança segue um de dois caminhos, e saber qual é qual evita frustração com prazo. O artigo de suporte do Bubble separa assim:

1. Atualização OTA (over the air): ajustes de interface, correções e mudanças de texto. Vai direto ao aparelho, é aplicada na próxima vez em que o usuário abre o app e não passa pela revisão da loja.
2. Build novo: funções novas, mudanças estruturais, mudanças de API ou qualquer coisa que exija revisão. Gera um arquivo novo, enviado ao App Store Connect ou ao Play Console, e passa pela revisão da Apple ou do Google.

Na prática, isso divide o roadmap em dois ritmos. Correção de texto, ajuste de layout e pequenos erros podem sair no mesmo dia. Uma função nova depende da fila de revisão da loja e consome um dos builds do mês. Planejar lançamentos em lotes, em vez de mandar cada melhoria isoladamente, protege a cota e reduz o número de vezes em que o app fica aguardando aprovação.

Há ainda armadilhas técnicas documentadas pelo próprio Bubble. No iOS, a Apple limita o número de certificados de distribuição por conta, e a plataforma recomenda não criar esse certificado manualmente, porque ela mesma o gera. No Android, o primeiro envio está previsto para falhar: ele gera o arquivo do app, que chega por e-mail e precisa ser carregado à mão no Play Console. Saber disso antes evita perder um dia achando que algo deu errado.

Web e mobile no mesmo projeto: o que se soma?

O plano do Bubble é comprado por projeto, e um projeto pode ter só o web app, só o app nativo ou os dois. A vantagem de manter os dois juntos é escrever a regra de negócio uma vez e ter um único banco de dados.

O custo dessa conveniência está numa frase da página de preços: como mobile e web compartilham backend e banco, todo o consumo de processamento é cumulativo. Se o web app já consumia boa parte da cota do plano, o lançamento do app nativo não traz uma cota nova; ele divide a mesma. É por isso que a projeção de consumo precisa ser refeita antes de publicar na loja, e não depois da primeira fatura.

Publicar na loja não cria uma segunda cota de processamento. Cria um segundo canal disputando a mesma.

Bubble, FlutterFlow ou Lovable: qual a diferença?

Os três aparecem juntos nas buscas porque prometem a mesma coisa, um app sem time grande de desenvolvimento, mas partem de lugares diferentes. A diferença que mais pesa para uma empresa é o que acontece com o código.

Bubble (suporte e preços), FlutterFlow (página de preços) e Lovable (documentação), consultados em 12/10/2026

O Bubble entrega a pilha inteira, interface, banco e regras, num lugar só, e cobra isso em dependência: a aplicação não sai como código. O FlutterFlow lista o download do código e a publicação na App Store a partir do plano pago Basic, segundo a página de preços do FlutterFlow. O Lovable se apresenta como construtor de aplicações web por linguagem natural e, pela documentação de integração com o GitHub, permite exportar e sincronizar o código num repositório próprio. A pergunta certa não é qual é melhor, e sim quanto custa sair de cada um daqui a três anos.

Quais os erros mais comuns de quem leva o Bubble para a loja?

• Prometer data de lançamento sem contar a revisão. A loja decide o próprio prazo, e uma recusa devolve o processo ao começo.
• Abrir a conta de desenvolvedor no nome de uma pessoa. Na Apple, a conta de empresa registra a pessoa jurídica como vendedora. Abrir no CPF de um sócio ou de um fornecedor complica a transferência depois.
• Gastar builds com correções que cabiam numa OTA. Texto e ajuste de tela não precisam de build novo; misturar os dois esgota a cota do mês.
• Esquecer a política de privacidade. É requisito das duas lojas quando o app coleta dados, e motivo de recusa.
• Não refazer a conta de consumo. Web e mobile somam o mesmo processamento, e o app nativo tende a aumentar o uso.
• Ir para a loja porque "app de verdade tem que estar na loja". Muitos projetos internos funcionam melhor como web app, sem revisão e sem taxa.

Quando basta o web app e quando vale o app nativo?

O critério mais útil não é a aparência, e sim a frequência e o contexto de uso. Uma ferramenta que a equipe abre algumas vezes por semana no computador ou no celular não ganha nada com a loja, e perde agilidade de atualização. Um app que o cliente final abre todo dia, que precisa ser encontrado na busca da loja e que depende de notificação no aparelho justifica o custo e o processo.

1. Fique no web app quando

• o público é interno ou é um grupo pequeno de clientes conhecidos;
• o produto ainda está em validação e muda toda semana;
• o acesso acontece por link enviado (e-mail, WhatsApp, portal).

2. Vá para a loja quando

• o cliente final usa o app com frequência e espera encontrá-lo na App Store ou no Google Play;
• notificação no aparelho é parte do produto;
• a marca precisa da presença na loja como sinal de confiança.

3. O que pedir ao fornecedor antes de contratar

1. Contas de desenvolvedor abertas no nome da sua empresa, com acesso administrativo seu.
2. Plano do Bubble escolhido pelo número de builds que o roadmap pede, não só pela cota de processamento.
3. Projeção de consumo somando web e mobile antes do lançamento.
4. Rotina de exportação dos dados testada, já que a aplicação não sai como código.
5. Calendário de lançamento que separe o que sai por OTA do que exige build novo.

Por onde começar

Comece pelo uso, não pela ferramenta: descreva quem abre o app, com que frequência e por qual caminho chega até ele. Se a resposta apontar para a loja, monte o cronograma com as contas da Apple e do Google, a política de privacidade e o teste fechado, quando ele se aplicar, antes de desenhar a primeira tela. Se apontar para o navegador, você economiza revisão, taxa e builds.

Vale olhar também a saída antes da entrada, como discutimos em low-code: a saída que ninguém desenha. Se quiser apoio nessa decisão, a nossa equipe de desenvolvimento low-code e no-code ajuda a escolher o caminho e a plataforma, e o diagnóstico de marketing gratuito mostra em que ponto está a sua operação digital antes de investir no aplicativo.