Existem dezenas de plataformas para criar aplicativos, e elas se agrupam em três famílias. Comparar produto por produto dentro da mesma família é detalhe; escolher a família errada é o erro que custa o projeto inteiro, e ele acontece porque a conta é feita só com o preço de entrada.
Este texto compara as três pelo que cobram depois: o que trava, o que precisa ser refeito e o que acontece no dia em que a assinatura termina.
As três famílias, e o que cada uma cobra depois
| Família | Quando serve | O que cobra depois |
|---|---|---|
| Nativo Kotlin no Android, Swift no iOS |
app que depende do aparelho: sensor, câmera com processamento, bluetooth, offline de verdade, desempenho gráfico | duas bases de código e dois conjuntos de habilidade, então todo recurso novo é feito duas vezes |
| Multiplataforma uma base para Android e iOS |
a maioria dos produtos de empresa: cadastro, pedido, agenda, consulta, integração com sistema | recurso muito específico do aparelho depende de biblioteca de terceiro, e o acabamento final consome mais tempo do que parece |
| Construtor sem código montagem visual, por assinatura |
validar ideia, uso interno simples, catálogo, formulário, agenda de equipe | teto de personalização, custo que cresce por usuário e dependência total do fornecedor |
Repare que a coluna da direita quase nunca aparece na comparação de quem está escolhendo. É ela que decide se, dois anos depois, o produto continua evoluindo ou vira refação.
Os nomes que você vai encontrar
Vale saber a que família cada nome pertence, porque a propaganda embaralha os três:
- Nativo. Kotlin com as ferramentas do Android e Swift com as ferramentas da Apple. É o que a própria fabricante do sistema recomenda, e o que sempre tem o recurso novo primeiro.
- Multiplataforma. Flutter, mantido pelo Google e escrito em Dart; React Native, mantido pela Meta e escrito em JavaScript ou TypeScript; Kotlin Multiplataforma, da JetBrains, que compartilha a regra de negócio e deixa a interface nativa em cada lado. Os três são maduros, e a escolha entre eles pesa mais pelo time disponível que pela lista de recursos.
- Construtor visual. Vai de ferramenta que gera projeto exportável, como o FlutterFlow, a plataformas fechadas de montagem por blocos, como Bubble, Adalo, Glide e as opções corporativas de Google e Microsoft ligadas a planilha e a fluxo interno. A diferença entre exportar e não exportar é a mais importante da lista.
Um alerta sobre comparação: “melhor ferramenta” não existe sem o contexto do time. Flutter com um desenvolvedor Flutter disponível é melhor que React Native, e o contrário também é verdade. A ferramenta que ninguém na sua região sabe manter é a pior de todas, por mais bem avaliada que esteja.
O que decide antes da tecnologia
Duas perguntas resolvem a maior parte da dúvida, e nenhuma delas é sobre linguagem:
- O aplicativo depende do aparelho? Câmera com leitura ou processamento, sensor, bluetooth com equipamento, mapa em uso contínuo, notificação crítica e funcionamento sem internet puxam para nativo ou multiplataforma. Cadastro com relatório não puxa para nada disso.
- Quantas plataformas, e quando? Se Android e iOS precisam existir juntos, multiplataforma quase sempre ganha. Se só uma importa por agora, nativo naquela plataforma é uma escolha defensável.
Existe uma terceira pergunta que muita empresa não faz e devia: precisa mesmo ser um aplicativo? Produto que é essencialmente um cadastro com relatório roda melhor como aplicação web responsiva, sem loja, sem atualização obrigatória e sem matriz de aparelhos. Aplicativo se justifica quando é preciso estar no aparelho. Antes de escolher plataforma, vale ler o guia de como criar um aplicativo e, principalmente, cortar o escopo: como definir o escopo do primeiro produto digital.
Sem código: onde funciona e onde é teto
Construtor visual tem uso legítimo, e o erro é tratá-lo como brinquedo ou como solução universal. Onde ele entrega:
- Validação. Colocar uma ideia na mão de usuário real em semanas, para descobrir se alguém quer aquilo, antes de investir em desenvolvimento.
- Uso interno de baixa complexidade. Checklist de equipe, formulário de campo, agenda, catálogo, aprovação simples.
- Operação pequena e estável, em que o app não é o produto e não vai mudar muito.
Onde bate no teto, e o sinal costuma aparecer no mesmo lugar:
- Regra de negócio própria. Quando a lógica que diferencia a empresa não cabe nos blocos disponíveis, começa a gambiarra, e ela é mais frágil que código.
- Integração com sistema interno. Ler e escrever no ERP, no banco de dados ou no legado da casa é onde a maioria dos construtores para.
- Custo por usuário. A assinatura que era barata com dez pessoas fica caríssima com quinhentas, e o modelo de cobrança é justamente por uso.
- Desempenho e experiência. Lista grande, animação, uso intenso: dá para notar, e o usuário nota.
A regra prática mais útil: sem código é excelente para descobrir o que construir, e ruim para sustentar o que virou o negócio.
Multiplataforma: o que se ganha e o que se paga
É a escolha padrão para a maioria dos produtos de empresa hoje, e por um motivo simples: uma base de código, dois aplicativos publicados, um time. O ganho de custo é real e aparece principalmente na manutenção, não na primeira entrega.
O que se paga tem dois nomes. O primeiro é dependência de biblioteca: todo recurso nativo específico chega pelo trabalho de terceiros, e quando a biblioteca não acompanha a versão nova do sistema, alguém precisa resolver. O segundo é o acabamento: fazer o app parecer nativo em detalhes de navegação, teclado e gesto é a parte que sempre demora mais do que a estimativa.
Para o caminho específico de cada loja e o que muda no Android, vale como criar um aplicativo Android, e para a conta do projeto, quanto custa criar um app.
As perguntas de saída
Plataforma boa é a que deixa você sair dela. Quatro perguntas para fazer antes de assinar qualquer coisa, e principalmente antes de escolher construtor visual:
- Dá para exportar o código? Se não dá, o produto existe enquanto a assinatura existir.
- De quem é a conta na loja? Conta de desenvolvedor no nome do fornecedor significa que o aplicativo publicado não é seu, e migrar exige recomeçar com outro endereço na loja.
- De quem são os dados, e como saem? Exportação completa, em formato aberto, sem depender de negociação comercial.
- O que acontece se a plataforma encerrar? Produto de construtor visual descontinuado deixa aplicativo no ar que ninguém consegue atualizar, e a atualização é obrigatória nas duas lojas.
Como decidir em quatro perguntas
- Precisa estar no aparelho? Se não, aplicação web resolve mais barato e sem loja.
- É para validar ou para operar? Validar aceita construtor visual; operar o que já é o negócio, não.
- Depende de recurso do aparelho? Muito: nativo ou multiplataforma com biblioteca madura. Pouco: qualquer uma das três.
- Quem vai manter em dois anos? Essa é a pergunta que elimina mais opções, porque tecnologia sem gente disponível para manter é dívida com data marcada.
Se o aplicativo nasceu de uma necessidade interna que a empresa já resolve com planilha, existe um caminho antes de escolher plataforma: entender o que aquilo pode virar, como em uma ferramenta interna que virou receita.
Perguntas frequentes
Quais são as plataformas para criar aplicativos?
Elas se agrupam em três famílias. Nativo, com Kotlin no Android e Swift no iOS, que é o que a fabricante do sistema recomenda e sempre tem o recurso novo primeiro. Multiplataforma, com Flutter, React Native e Kotlin Multiplataforma, que entrega os dois sistemas a partir de uma base de código. E construtor visual, que monta o aplicativo por blocos e é vendido por assinatura. Comparar produtos dentro da mesma família é detalhe; escolher a família errada custa o projeto.
Qual é a melhor ferramenta para desenvolver app?
Não existe melhor sem o contexto do time. Flutter é melhor que React Native quando existe alguém disponível que sabe Flutter, e o contrário também é verdade. A ferramenta que ninguém na sua região sabe manter é a pior de todas, por mais bem avaliada que esteja nas comparações. A pergunta certa não é qual é a melhor, é quem vai manter isso em dois anos.
Qual a diferença entre nativo e multiplataforma?
Nativo é uma base de código por sistema, o que significa dois times, ou um time com duas habilidades, e todo recurso novo feito duas vezes. Multiplataforma é uma base para os dois, com ganho de custo que aparece principalmente na manutenção. A troca é dupla: recurso muito específico do aparelho depende de biblioteca de terceiro, e o acabamento para o app parecer nativo em navegação, teclado e gesto sempre demora mais que a estimativa.
Dá para criar aplicativo sem programar?
Dá, e tem uso legítimo: validar uma ideia com usuário real em semanas, uso interno de baixa complexidade como checklist, formulário de campo, agenda e catálogo, e operação pequena e estável em que o app não é o produto. A regra prática é essa: construtor visual é excelente para descobrir o que construir, e ruim para sustentar o que virou o negócio.
Quando o no-code bate no teto?
Em quatro pontos, e o sinal aparece sempre nos mesmos lugares. Regra de negócio própria, quando a lógica que diferencia a empresa não cabe nos blocos e começa a gambiarra. Integração com sistema interno, para ler e escrever no ERP ou no legado da casa. Custo por usuário, porque a assinatura barata com dez pessoas fica caríssima com quinhentas. E desempenho, em lista grande e uso intenso, que o usuário percebe.
O que perguntar antes de assinar uma plataforma?
Quatro perguntas de saída, porque plataforma boa é a que deixa você sair dela. Dá para exportar o código, ou o produto existe enquanto a assinatura existir? De quem é a conta na loja, porque conta no nome do fornecedor significa que o app publicado não é seu? De quem são os dados e como eles saem, em formato aberto? E o que acontece se a plataforma encerrar, já que a atualização é obrigatória nas duas lojas?
FlutterFlow, Bubble e Adalo são a mesma coisa?
Não, e a diferença que importa é uma: se o projeto pode ser exportado. Ferramenta que gera um projeto real, como o FlutterFlow com Flutter, permite que um time assuma o código depois. Plataforma fechada de montagem por blocos entrega um aplicativo que só existe dentro dela. Isso não desqualifica a segunda, mas muda o tipo de decisão: uma é escolha de tecnologia, a outra é dependência de fornecedor.
Preciso mesmo de um aplicativo?
É a pergunta que mais economiza dinheiro e a que menos se faz. Produto que é essencialmente um cadastro com relatório roda melhor como aplicação web responsiva: sem loja, sem atualização obrigatória, sem matriz de aparelhos e com correção publicada na hora. Aplicativo se justifica quando é preciso estar no aparelho, com notificação, uso offline, câmera ou sensor. Muita empresa paga duas lojas para descobrir isso depois.
Quanto custa desenvolver em cada família?
Construtor visual tem o menor custo de entrada e o maior custo de saída. Multiplataforma costuma ser o melhor custo total para produto de empresa, porque a manutenção é única. Nativo é o mais caro de manter e o único caminho quando o app depende intensamente do aparelho. O que mais mexe no orçamento, em qualquer uma das três, é a quantidade de telas com regra própria e o backend, que costuma ser a maior parte do trabalho.
Como decidir a plataforma em quatro perguntas?
Primeira: precisa estar no aparelho? Se não, aplicação web resolve mais barato. Segunda: é para validar ou para operar? Validar aceita construtor visual, operar o que já é o negócio não. Terceira: depende de recurso do aparelho? Muito depende puxa para nativo ou multiplataforma com biblioteca madura. Quarta: quem vai manter em dois anos? Essa elimina mais opções que as outras três juntas.
