Um aplicativo mobile carrega um custo que vai muito além do desenvolvimento inicial: publicação e manutenção da conta em duas lojas, adequação a cada nova versão dos sistemas operacionais, suporte a uma variedade de aparelhos, atualizações que o usuário precisa baixar e um ciclo de aprovação da Apple e do Google a cada mudança. Ele se justifica quando entrega algo que a web não entrega — e não se justifica quando é apenas uma versão do site dentro de um ícone.

Este artigo ajuda a fazer essa distinção antes de o orçamento ser aprovado, quando ainda é barato mudar de ideia.

O que só um app entrega bem

Existem capacidades que, na prática, funcionam melhor ou só funcionam em um aplicativo nativo:

  • Uso offline — o app funciona sem conexão e sincroniza depois. Essencial para operação em campo, logística, áreas remotas.
  • Recursos do aparelho — câmera integrada a fluxos, leitura de código de barras e NFC, sensores, Bluetooth com periféricos.
  • Notificações push confiáveis — a web também tem, mas com alcance e confiabilidade menores, especialmente no iOS.
  • Presença na tela inicial — o ícone do app disputa atenção todo dia; um site favoritado, não.
  • Performance de interações complexas — animações, gestos, listas enormes, edição rica — mais fluidas em código nativo.
  • Integração com o sistema — compartilhamento, widgets, atalhos, login biométrico.

Sinais de que um app faz sentido

  1. O mesmo usuário volta com frequência — idealmente diária ou semanal, não uma vez por trimestre.
  2. A jornada depende de pelo menos um recurso do aparelho ou de uso offline.
  3. A experiência ganha valor real por estar sempre a um toque de distância.
  4. Há um relacionamento contínuo a manter, e as notificações têm papel legítimo nesse relacionamento.
  5. O volume de usuários e a receita por usuário justificam manter duas plataformas vivas.

Sinais de que talvez não

Se o objetivo é principalmente presença de marca, se o uso é esporádico (comprar uma passagem uma vez por ano, consultar um extrato de tempos em tempos), ou se um site responsivo bem-feito já resolve a jornada, o investimento em app raramente compensa. Um app pouco usado ainda custa manutenção, ainda precisa de atualização de segurança e ainda ocupa espaço no aparelho de quem baixou e não voltou.

Há também o custo de aquisição: convencer alguém a baixar um app é muito mais difícil do que fazer a pessoa abrir um link. Cada passo — encontrar na loja, baixar, criar conta, permitir notificações — perde usuários.

As alternativas

Site responsivo

Para a maioria dos negócios, um site que funciona bem no celular resolve. É acessível por link, indexável, não exige instalação e tem um único código para manter. A evolução recente de CSS e JavaScript permite experiências mobile bastante sofisticadas.

PWA (Progressive Web App)

Um site que pode ser “instalado” na tela inicial, funciona parcialmente offline e recebe notificações (com limitações no iOS). É um meio-termo interessante quando você quer alguns benefícios do app sem o custo de duas bases nativas e sem depender das lojas.

App híbrido

Uma base de código só, empacotada para as duas lojas, usando tecnologias web ou frameworks como React Native e Flutter. Reduz o custo de manter duas plataformas, com trade-offs de performance e de acesso a recursos muito específicos. É a escolha padrão hoje para a maioria dos apps de negócio.

Os custos reais de um app

  • Desenvolvimento — maior do que um site equivalente, especialmente se for nativo nas duas plataformas.
  • Contas de desenvolvedor — anuidade da Apple, taxa única do Google, com processos de verificação.
  • Manutenção contínua — cada versão nova de iOS e Android pode exigir ajustes; APIs são descontinuadas; requisitos das lojas mudam.
  • Backend — quase todo app precisa de servidor, API e infraestrutura própria.
  • Submissão e revisão — cada atualização passa por aprovação, o que adiciona dias ao ciclo e pode gerar rejeições.
  • Suporte — usuários com aparelhos e versões diferentes, avaliações públicas na loja que precisam de resposta.
  • Marketing — promover a instalação é um custo recorrente por si só.

Antes de decidir: mapear a jornada

A pergunta certa não é “queremos um app?”, e sim “em que ponto da jornada do usuário um app adiciona valor que a web não adiciona?”. Mapeie o fluxo completo — descoberta, primeiro uso, uso recorrente, situações de exceção — e marque onde offline, câmera, notificação ou presença fazem diferença concreta. Se não houver nenhum ponto assim, provavelmente você precisa de um site melhor, não de um app.

Se houver, o mapa também mostra o escopo mínimo do app: nem tudo precisa estar nele. Muitos produtos funcionam com um app enxuto para o uso recorrente e um site completo para o resto.

Lançar: nem tudo de uma vez

Quando o app se justifica, o erro comum é tentar lançar com paridade total de funcionalidades em relação ao site. Isso infla o escopo e adia o aprendizado. O caminho melhor é lançar com o núcleo — o que traz o usuário de volta com frequência — e evoluir a partir do uso real, com a mesma disciplina de qualquer produto: monitoramento, análise de comportamento, iteração.

Manutenção: um app nunca está “pronto”

Diferente de um site, um app tem um relógio correndo: a cada ano, novas versões de sistema operacional podem quebrar comportamentos, exigir novas permissões ou impor requisitos de compilação. Um app abandonado por um ano frequentemente para de funcionar ou é removido da loja. O orçamento precisa prever essa manutenção mínima, mesmo em períodos sem novas funcionalidades.

Notificações: uma ferramenta que se gasta

A capacidade de enviar notificações é frequentemente o principal argumento para um app — e a principal forma de perder o usuário. Notificação irrelevante, frequente demais ou puramente promocional leva a pessoa a desligar as notificações (e às vezes desinstalar). Uma vez desligadas, é muito difícil reconquistar a permissão.

Notificação boa é a que o usuário agradeceria: algo que ele esperava, no momento em que faz diferença. Vale ter uma política clara — quais eventos geram notificação, com que frequência máxima, com qual possibilidade de o usuário escolher o que recebe — antes de lançar, não depois de já ter queimado a audiência.

O app como parte de um ecossistema

Um app raramente vive sozinho. Ele consome dados de um backend, que muitas vezes também alimenta um site e sistemas internos. Pensar o app isoladamente leva a duplicar regras de negócio, criar inconsistências entre canais e dificultar a manutenção.

O desenho saudável é ter as regras de negócio centralizadas no backend, expostas por uma API bem definida, e o app (assim como o site) como um consumidor dessa API. Assim, uma mudança de regra vale para todos os canais de uma vez.

Métricas que dizem se valeu a pena

  • Retenção — quantos usuários voltam depois de 1, 7 e 30 dias.
  • Frequência de uso por usuário ativo.
  • Proporção de usuários que ativam as funcionalidades que justificaram o app (offline, câmera, notificação).
  • Custo de aquisição por instalação ativa versus valor gerado por usuário.
  • Avaliação média na loja e volume de suporte.
  • Taxa de usuários que mantêm as notificações ativadas.

Se a retenção é baixa e quase ninguém usa os recursos exclusivos, o app está competindo com o próprio site — e perdendo.

Nativo, híbrido ou web: comparando os caminhos

A escolha da tecnologia não é neutra e afeta custo, prazo e experiência. Um resumo prático:

  • Nativo (Swift/Kotlin) — melhor performance e acesso total aos recursos, ao custo de duas bases de código e dois times de conhecimento. Justifica-se quando a experiência é o diferencial e o orçamento comporta.
  • Híbrido (React Native, Flutter) — uma base de código para as duas lojas, performance boa para a maioria dos casos, comunidade grande. É a escolha padrão para apps de negócio hoje.
  • PWA — sem lojas, sem instalação tradicional, um código só compartilhado com o site. Limitações de recursos, principalmente no iOS, mas o menor custo total.
  • Wrapper de site — empacotar o site responsivo como app. Barato, mas costuma resultar em uma experiência que os usuários percebem como “só o site”, e as lojas às vezes rejeitam.

O que a loja exige e o que pode dar errado na publicação

Publicar não é só subir o arquivo. A Apple e o Google revisam cada versão e podem rejeitar por motivos que vão de bugs a questões de política: permissões pedidas sem justificativa clara, conteúdo que infringe diretrizes, falta de política de privacidade, funcionalidades que parecem incompletas. A App Store historicamente é mais rigorosa.

Cada rejeição adiciona dias ao ciclo. Vale conhecer as diretrizes antes de construir, preparar as respostas para os pontos sensíveis (por que o app precisa da câmera, da localização) e ter margem no cronograma para uma ou duas rodadas de revisão.

Privacidade e dados no mobile

Apps têm obrigações específicas de privacidade: declaração dos dados coletados nas fichas das lojas, pedido de consentimento para rastreamento no iOS, cuidado redobrado com permissões. Coletar menos dados, pedir permissão só quando o recurso é usado e explicar o porquê melhora tanto a conformidade quanto a taxa de aceitação dos usuários.

Como a Jumps aborda

A Jumps desenvolve aplicativos com foco em produto: primeiro o mapeamento da jornada para confirmar onde o app agrega valor, depois a escolha da tecnologia adequada ao caso, um escopo enxuto de lançamento e evolução contínua conectada ao backend e às integrações necessárias. Quando um site responsivo ou um PWA resolvem melhor, dizemos isso.

Se você está avaliando um aplicativo, fale com a Jumps antes de fechar o escopo.