Guia de desenvolvimento de aplicativo mobile no Brasil: quando fazer, custo, arquitetura e publicação

O que este guia cobre

Quase toda empresa que me procura para falar de app começa a conversa pela tela. Querem mostrar o layout, a cor do botão, a animação de entrada. Poucas começam pela pergunta que decide tudo: por que um app, e não um site responsivo ou um sistema web que roda no navegador do celular. Essa é a primeira coisa que separa um projeto que dá retorno de um que vira um ícone abandonado na tela do usuário depois de três meses.

Escrevi este guia para quem precisa decidir com base em algo além de folheto. Vou tratar de quando um app faz sentido de verdade, da escolha entre nativo, React Native e Flutter, do custo real por faixa de complexidade, da arquitetura que sustenta o aplicativo por baixo da interface, da publicação nas lojas, da manutenção que ninguém orça e do momento em que vale construir sob medida em vez de comprar pronto. Os números vêm de projetos que entregamos na Bradata e de orçamentos que clientes trouxeram de concorrentes para segunda opinião.

É um texto longo. Use os títulos para ir direto ao que interessa agora.

Quando um app faz sentido, e quando não faz

O celular é a plataforma óbvia, e por isso mesmo muita gente pede um app quando um site já resolveria. Vale ser honesto sobre isso antes de gastar dinheiro.

Um app nativo instalado no aparelho ganha de um site em quatro situações concretas. A primeira é uso offline ou com conexão ruim: entregador em rota, técnico em campo, vendedor em galpão sem sinal. A segunda é acesso profundo ao hardware: câmera com leitura contínua de código de barras, GPS em segundo plano, Bluetooth para impressora térmica ou balança, biometria. A terceira é notificação push confiável, que puxa o usuário de volta sem depender de e-mail. A quarta é uso frequente e diário, em que o atrito de abrir o navegador e digitar um endereço pesa.

Se o seu caso não cai em nenhuma dessas, provavelmente você quer um sistema web responsivo, não um app. Um web app bem feito abre no celular, funciona em qualquer aparelho, não passa pela revisão da loja e custa menos para manter. Empurrar tudo para um app nativo quando um PWA resolveria é o erro que mais vejo, e ele cobra caro na manutenção.

O contraponto: quando o app é a ferramenta de trabalho de campo, ele deixa de ser luxo e vira infraestrutura. Um app de coleta que funciona sem sinal e sincroniza depois não tem substituto no navegador. Aí o investimento se paga em produtividade medível.

Nativo, React Native ou Flutter

Essa decisão define entre 20% e 40% do custo total e mexe na velocidade de entrega e na manutenção pelos anos seguintes. Vale entender antes de negociar.

Nativo significa Swift para iOS e Kotlin para Android, duas bases de código separadas. Dois times, ou um time que escreve a interface duas vezes. Você ganha acesso total ao hardware, performance máxima e comportamento idêntico ao que o sistema operacional espera. Paga com o custo da interface praticamente dobrando quando quer as duas plataformas. Faz sentido para apps com gráfico pesado, processamento de vídeo em tempo real, realidade aumentada ou uso intenso de sensores de baixo nível.

React Native usa uma base única em JavaScript ou TypeScript que gera as duas versões. Você escreve a lógica uma vez. Um app React Native custa entre 30% e 45% menos que dois nativos equivalentes. A perda de performance é irrelevante para o app empresarial típico: formulários, listas, dashboards, leitura de código de barras, GPS, câmera para documentos. O ecossistema é grande e encontrar desenvolvedor no Brasil é fácil, o que reduz risco de dependência de uma pessoa só.

Flutter usa Dart e desenha a própria interface, sem depender dos componentes do sistema. Entrega performance de animação muito boa e visual idêntico entre plataformas. O preço é um pool menor de desenvolvedores no Brasil e uma linguagem que a maioria dos times ainda não domina. Brilha quando o design é forte e uniforme entre iOS e Android é requisito.

Critério	Nativo	React Native	Flutter
Custo relativo (2 plataformas)	Alto	Médio	Médio
Performance gráfica extrema	Melhor	Boa	Muito boa
Acesso ao hardware	Total e imediato	Bom, às vezes via ponte	Bom, às vezes via ponte
Disponibilidade de dev no Brasil	Média	Alta	Média/baixa
Time-to-market	Mais lento	Rápido	Rápido
Maturidade do ecossistema	Máxima	Alta	Alta

Para 8 em cada 10 apps empresariais que passam pela nossa mesa, React Native é a escolha certa. A economia é real e o usuário não percebe diferença. Se alguém empurra nativo para um app de gestão de campo ou catálogo de vendas, peça a justificativa técnica, porque geralmente não existe. O detalhe de cada trade-off, com números de benchmark, está em React Native vs Flutter vs nativo em 2026, e recomendo essa leitura antes de fechar a decisão de plataforma.

O custo real, por faixa de complexidade

O erro mais caro ao pedir orçamento de app é tratar o aplicativo como se fosse o produto inteiro. Não é. O app é a ponta visível. Debaixo dele tem backend, banco de dados, autenticação, integrações, painel administrativo e infraestrutura. Quando alguém diz que fez o app por R$ 25 mil, ou o app não conversa com nada, ou o backend foi cobrado à parte e ninguém contou.

As faixas abaixo consideram o sistema completo, app mais backend mais painel, em React Native, com um time misto e escopo bem definido. São faixas reais, não "a partir de".

Complexidade	O que inclui	Faixa de investimento	Prazo típico
Simples	Login, listas, formulários, uma integração, push básico	R$ 60 mil a R$ 120 mil	2 a 4 meses
Média	Offline parcial, várias integrações, painel admin, perfis de acesso	R$ 120 mil a R$ 280 mil	4 a 7 meses
Alta	Offline-first robusto, sync de conflito, mapa, pagamento, alta escala	R$ 280 mil a R$ 600 mil+	7 a 12 meses

O que empurra o número para cima raramente é a tela. É a regra de negócio escondida, a integração com um ERP legado sem API decente, a exigência de funcionar sem sinal e a necessidade de escalar para milhares de usuários simultâneos. A conta detalhada, item por item, está em quanto custa um app mobile empresarial, e vale abrir esse artigo quando estiver comparando propostas, porque ele mostra onde os orçamentos escondem custo.

Um alerta prático: desconfie de orçamento redondo e baixo sem discovery. Um app sério começa com uma fase de descoberta que define escopo, integrações e riscos. Quem dá preço fechado antes de entender o problema está chutando, e o chute vira aditivo de contrato lá na frente.

A arquitetura por baixo da interface

Aqui está a parte que decide se o app vai aguentar crescer ou vai virar um problema em dezoito meses. A interface é o que se vê. A arquitetura é o que sustenta.

Backend e API

O app é um cliente. Ele precisa de um backend que guarde os dados, aplique as regras e converse com os outros sistemas da empresa. Na maioria dos casos o backend expõe uma API REST ou GraphQL que o app consome. A decisão de arquitetura do backend importa mais que a do app: é ali que a escala, a segurança e a integração vivem. Se o backend for bem desenhado, trocar de tecnologia no app depois é possível. O contrário quase nunca é verdade.

Um ponto que muita empresa ignora: o painel administrativo. Alguém precisa cadastrar usuários, ver relatórios, corrigir dados e configurar regras. Esse painel é um sistema web que compartilha o mesmo backend do app. Ele costuma custar de 20% a 40% do projeto e some dos orçamentos apressados, o que gera surpresa desagradável no meio do caminho.

Offline-first quando o campo exige

Se o app roda onde falta sinal, offline não é enfeite, é requisito de arquitetura. Offline-first significa que o app funciona lendo e gravando num banco local no aparelho, geralmente SQLite, e sincroniza com o servidor quando a conexão volta. O difícil não é guardar dado local. É resolver conflito: o que acontece quando dois usuários alteram o mesmo registro offline e sincronizam depois.

Essa parte é engenharia séria, não um plugin. Envolve estratégia de resolução de conflito, controle de versão de registro, fila de sincronização resiliente e cuidado com bateria, porque sync mal feito drena o aparelho e o usuário desinstala. Documentamos um blueprint completo disso em app offline-first para frota com SQLite e sync, com as decisões que evitam corrupção de dado e consumo excessivo de bateria. Se o seu app é de campo, leia antes de aprovar arquitetura.

Notificação push

Push parece trivial e tem detalhe. iOS usa o serviço da Apple, Android usa o Firebase Cloud Messaging. Você precisa de um serviço no backend que dispare as notificações, trate tokens que expiram e respeite as regras de cada plataforma. Push transacional, aquele que avisa que um pedido saiu para entrega, é diferente de push de marketing, que exige consentimento e cuidado com LGPD. Misturar os dois no mesmo canal irrita o usuário e derruba a taxa de quem mantém as notificações ligadas.

Sincronização e consistência

Mesmo apps que não são offline-first precisam pensar em sincronização. O celular perde conexão, o usuário fecha o app no meio de uma ação, a rede oscila. A arquitetura precisa tolerar isso sem duplicar pedido, sem perder dado e sem travar. Idempotência nas chamadas, ou seja, garantir que repetir a mesma requisição não gera dois registros, é um detalhe técnico que separa o app confiável do app que gera dor de cabeça no financeiro.

Publicação nas lojas

Ter o app pronto não é o fim. Colocá-lo na App Store e na Google Play tem processo, custo e regra que atrasam quem não planeja.

Na Apple, você precisa de uma conta de desenvolvedor que custa 99 dólares por ano, e a conta deve estar no nome da empresa, com verificação de identidade que leva dias. A revisão da Apple é humana e criteriosa. Ela rejeita app que usa login social sem oferecer a opção da Apple, que coleta dado sem política de privacidade clara, que tem tela vazia ou função quebrada. Uma rejeição custa de dois a sete dias de reenvio. Planeje isso no cronograma.

O Google Play tem conta de desenvolvedor com taxa única de 25 dólares e revisão mais automatizada, porém mais lenta que no passado, e hoje leva de horas a alguns dias. O Google endureceu a exigência de teste fechado antes de publicar app de conta nova, então há um período de validação com usuários reais antes da liberação pública. Isso pega de surpresa quem esperava publicar no mesmo dia.

Item	App Store (Apple)	Google Play
Conta de desenvolvedor	99 USD por ano	25 USD (única)
Tipo de revisão	Humana, rigorosa	Mista, mais rápida
Tempo até publicar	1 a 7 dias	Horas a dias
Rejeição comum	Privacidade, login Apple, função quebrada	Política de dados, permissões

Para app corporativo de uso interno, existe distribuição sem loja pública: o programa de distribuição empresarial da Apple e o gerenciamento por MDM. Isso evita a revisão pública e faz sentido quando o app é só para funcionários. É um caminho técnico específico que vale avaliar caso a caso.

Manutenção: o custo que ninguém orça

O app não termina no lançamento. Ele vive num ambiente que muda sem pedir licença. iOS e Android lançam versão nova todo ano e podem quebrar o que funcionava. Bibliotecas ficam obsoletas. A Apple e o Google mudam regra de loja e obrigam atualização. Se o app parar de ser atualizado, em um ou dois anos ele começa a falhar em aparelhos novos e some das buscas.

A conta realista de manutenção fica entre 15% e 25% do custo de desenvolvimento por ano. Isso cobre correção de bug, adaptação a novas versões de sistema operacional, atualização de dependência, ajuste de regra de loja e pequenas melhorias. Orçamento de app que não inclui essa linha está incompleto, e o cliente descobre isso da pior forma quando o app quebra e ninguém tem contrato para consertar.

Vale separar manutenção de evolução. Manutenção é manter vivo. Evolução é adicionar função nova, e essa é orçada à parte, como projeto. Confundir as duas gera briga de escopo. Deixe claro no contrato o que é cada coisa.

Comprar pronto ou construir sob medida

Nem todo app precisa ser feito do zero. Existem plataformas que geram app de catálogo, de delivery, de agendamento. Se o seu caso é padrão e o produto pronto atende, assine e economize. Construir sob medida o que já existe de prateleira é queimar dinheiro.

Sob medida faz sentido em três situações. A primeira é quando o processo que o app apoia é diferencial competitivo, não commodity, e moldar o app à sua operação vale mais que adaptar a operação ao app. A segunda é quando a integração com sistemas internos é profunda e o produto pronto não conversa com o seu ERP ou seu WMS. A terceira é quando a escala e o controle sobre os dados justificam ter a plataforma sob seu domínio, sem depender de um fornecedor que pode mudar preço ou encerrar o serviço.

A conta que orienta a decisão é de anos, não de mês. Um SaaS de app cobra por usuário e por mês, e para poucos usuários é barato. Conforme a base cresce, a mensalidade escala e em algum ponto o sob medida, que tem custo grande na frente e barato depois, passa a valer mais. Faça a conta de cinco anos antes de descartar qualquer caminho. Se o seu app é peça central da operação de campo ou comercial, vale conhecer como estruturamos um app mobile corporativo sob medida, com backend próprio e integração ao que já roda na empresa.

Um caminho de projeto que não fracassa

Depois de tudo, um projeto de app saudável segue uma sequência. Primeiro, valide se você precisa mesmo de app ou se um web app resolve, porque essa decisão economiza o maior dinheiro. Segundo, faça uma fase de discovery que define escopo, integrações e riscos antes de qualquer preço fechado. Terceiro, escolha a plataforma pela justificativa técnica, e na dúvida vá de React Native. Quarto, desenhe o backend com cuidado, porque é ele que sustenta escala e integração. Quinto, se o campo exige, trate offline-first como requisito de engenharia desde o início, não como remendo. Sexto, planeje publicação nas lojas com folga no cronograma. Sétimo, orce a manutenção anual desde o começo.

O erro que afunda projeto de app não é gastar na tela. É subestimar o que existe por baixo dela e esquecer que o app precisa ser mantido vivo por anos. Trate o app como um sistema, não como uma imagem bonita, e ele devolve retorno.

Perguntas frequentes

Quanto tempo leva para desenvolver um app? Um app simples com backend entra no ar em 2 a 4 meses. Um app de média complexidade leva de 4 a 7 meses, e um app de alta complexidade com offline-first e alta escala passa de 7 meses. O que mais atrasa não é a programação, é a definição de escopo mal feita e a integração com sistemas legados sem API. Desconfie de quem promete app completo em quatro semanas sem discovery.

Preciso mesmo de um app ou um site resolve? Depende do uso. Se o seu caso exige funcionar offline, acesso ao hardware do celular, push confiável ou uso diário intenso, o app se justifica. Se não, um web app responsivo abre no celular, funciona em qualquer aparelho, não passa pela revisão da loja e custa menos para manter. Muita empresa pede app quando um site já resolveria.

React Native perde muito para nativo? Para o app empresarial típico, a diferença é imperceptível para o usuário. Formulários, listas, dashboards, câmera, GPS e leitura de código de barras funcionam bem em React Native, com economia de 30% a 45% frente a dois apps nativos. Você só sente a diferença em casos extremos de performance gráfica, como vídeo em tempo real ou realidade aumentada.

Quanto custa manter um app depois do lançamento? Entre 15% e 25% do custo de desenvolvimento por ano. Isso cobre correção de bug, adaptação a novas versões de iOS e Android, atualização de bibliotecas e ajuste às mudanças de regra das lojas. Adicionar funções novas é evolução, orçada à parte. Orçamento que ignora a manutenção está incompleto.

Por que meu app foi rejeitado na App Store? As causas mais comuns são política de privacidade ausente ou vaga, falta da opção de login da Apple quando há outros logins sociais, funções quebradas na versão enviada e uso de permissões sem justificativa. A revisão da Apple é humana e criteriosa. Cada rejeição custa de dois a sete dias de reenvio, então vale preparar tudo antes de submeter.

Vale a pena fazer um app sob medida ou usar uma plataforma pronta? Se o seu caso é padrão e o produto pronto atende, assine e economize. Sob medida vale quando o processo é diferencial competitivo, quando a integração com sistemas internos é profunda ou quando a escala e o controle sobre os dados justificam ter a plataforma sob seu domínio. Faça a conta de cinco anos, não de um mês, antes de decidir.

Fechamento

Um app bem feito é um sistema completo com tela de celular na ponta: backend, integrações, painel, sincronização e infraestrutura sustentando a experiência. O erro caro não é escolher a linguagem errada, é tratar o app como imagem e ignorar a engenharia que o mantém de pé e vivo por anos. Valide a necessidade, desenhe o backend com cuidado, escolha a plataforma pela técnica e orce a manutenção desde o dia um.

Se você quer avaliar se o seu caso pede um app de verdade e como estruturar o projeto sem surpresa de escopo, a Bradata já entregou apps de campo, catálogo e operação com backend próprio e integração ao ERP do cliente. Fale com a gente para uma conversa sem folheto.