Apps

Aplicativo na loja ou site que instala no celular: qual dos dois a sua empresa precisa

08/09/2026 11 min de leitura

Nem todo aplicativo precisa estar na App Store e na Google Play. Um site pode ganhar ícone na tela do celular, funcionar sem internet e enviar notificação, sem loja, sem aprovação e sem porcentagem. Veja quando cada caminho vale, o que custa cada um e o que você entrega ao escolher a loja.

A conversa quase sempre começa do mesmo jeito. Alguém da equipe diz que a empresa precisa de um aplicativo, e a frase seguinte já é sobre a App Store e a Google Play, como se as duas coisas fossem inseparáveis. Elas não são.

Existe um caminho intermediário que resolve boa parte dos casos e que quase nunca entra na conversa: um site que se instala no celular. Ele ganha ícone na tela inicial, abre em tela cheia sem barra de navegador, funciona com internet ruim, guarda dados no aparelho e pode enviar notificação. Não passa por loja, não espera aprovação e não divide receita com ninguém.

Isso não substitui o aplicativo nativo em todos os cenários, e prometer que substitui é desonesto. Mas escolher o caminho caro sem saber que o barato existia é o erro mais comum desse tipo de projeto, e ele custa meses e dezenas de milhares de reais.

Os três caminhos possíveis, sem jargão

Na prática, o que se chama de aplicativo de empresa cai em uma destas três categorias.

  • Aplicativo nativo. Programado para cada sistema, publicado na App Store e na Google Play, instalado pela loja. Acessa tudo que o aparelho oferece e é o caminho mais caro e mais demorado.
  • Aplicativo multiplataforma. Um código só que gera as duas versões. Mais barato que o nativo puro, ainda passa pelas lojas e ainda depende de aprovação e de atualização baixada pelo usuário.
  • Site instalável. Uma aplicação web que o navegador oferece instalar no aparelho. Roda no celular e no computador, atualiza sozinha e não depende de loja nenhuma.

Os três entregam um ícone na tela do usuário. O que muda é quanto custa chegar lá, quem controla a distribuição e o que o programa consegue fazer depois de instalado.

O que o site instalável já faz bem

A lista é maior do que a reputação do formato sugere, e ela cobre a maior parte do que uma empresa média pede quando diz que quer um aplicativo.

  • Ícone na tela inicial e abertura em tela cheia, sem barra de endereço, com a marca no lugar da identidade do navegador.
  • Funcionamento com conexão ruim ou ausente, servindo telas e dados guardados na última visita.
  • Notificação push, inclusive no iPhone, para aparelhos com sistema atualizado.
  • Câmera, arquivos, localização e leitura de código, que cobrem a maioria dos usos de campo, como registrar visita, tirar foto de ocorrência ou bipar um produto.
  • Uma base de código só para celular, tablet e computador, com uma equipe só mantendo.
  • Atualização instantânea. Você publica e todo mundo está na versão nova no próximo acesso.

Esse último ponto é subestimado e vale mais do que parece. Aplicativo de loja convive com usuários espalhados por várias versões antigas, o que obriga a manter compatibilidade com telas que você gostaria de ter aposentado. Isso é custo recorrente e é invisível no orçamento inicial do projeto.

O que ainda exige aplicativo de verdade

Existe uma fronteira, e ela é honesta. Se o seu caso está do outro lado dela, o site instalável não resolve e insistir sai mais caro do que ter começado certo.

  • Uso pesado de recursos do aparelho, como bluetooth com equipamento específico, leitura de etiqueta por aproximação, sensores industriais ou processamento local intenso.
  • Rodar em segundo plano de forma contínua, como rastreamento de rota enquanto o aplicativo está fechado.
  • Compra dentro do aplicativo de conteúdo digital, que as lojas exigem que passe pelo sistema delas.
  • Presença na loja como canal de descoberta, quando o usuário procura na busca da loja e é assim que ele encontra você.
  • Exigência do cliente ou do mercado, quando estar na loja é requisito de contrato ou de percepção de credibilidade em um setor específico.

Repare que apenas as três primeiras são limitações técnicas. As duas últimas são decisões de mercado, e elas são legítimas: se o seu cliente só acredita no que está na Google Play, isso é um fato do seu negócio, não uma opinião a ser corrigida.

O custo real, e o que não aparece na proposta

A comparação de preço costuma parar no desenvolvimento, que é a parte menor do custo de vida de um aplicativo.

No caminho da loja, além do desenvolvimento, existem as contas de desenvolvedor, com renovação anual em uma delas e cobrança única na outra. Existe o processo de publicação, que consome tempo de alguém a cada versão. Existe a fila de revisão, que pode aprovar em horas ou pedir ajustes por semanas. Existe a obrigação de acompanhar mudanças de política das plataformas, que acontecem sem aviso e às vezes exigem alteração no seu produto para continuar publicado. E existe o suporte às versões antigas que os usuários não atualizaram.

No site instalável, esse bloco inteiro desaparece. Sobra hospedagem, domínio e certificado, que a empresa já paga se tem site. A publicação é um deploy. A revisão não existe. A política de plataforma não se aplica.

Não estou dizendo que um é sempre mais barato que o outro em desenvolvimento, porque isso depende do escopo. Estou dizendo que o custo de manutenção do caminho da loja é estruturalmente maior, e que ele continua correndo depois que o projeto acaba.

Quem controla a distribuição controla o produto

Aqui está a parte que raramente entra na planilha e que costuma ser a mais cara quando dá errado.

Ao publicar na loja, você aceita que uma empresa fora da sua decida se o seu aplicativo pode existir, quando a atualização vai ao ar, quais formas de cobrança são permitidas e sob quais regras a sua conta permanece ativa. Isso funciona bem na maior parte do tempo e é a razão pela qual a maioria nem pensa no assunto.

Funciona mal no dia em que uma revisão trava uma correção urgente, ou em que uma mudança de política obriga a alterar o funcionamento do seu produto, ou em que uma conta é suspensa por um motivo automático e o suporte responde por formulário. É o mesmo risco que a empresa corre quando concentra a presença digital em perfil de rede social, assunto que já tratamos ao falar do que acontece quando a conta do Instagram é bloqueada.

A presença digital da empresa tem que ser dela. Domínio, site, e-mail e sistema sob controle próprio, não emprestados de plataforma de terceiro. O site instalável mantém a distribuição na sua mão, porque o endereço é seu, e endereço próprio não é suspenso por política de conteúdo.

Como decidir sem depender de opinião

Quatro perguntas resolvem a maior parte dos casos, e todas elas são sobre o negócio, não sobre tecnologia.

  1. Quem vai usar isso? Cliente final, equipe interna ou parceiro. Aplicação interna quase nunca precisa de loja, porque a distribuição é você quem faz.
  2. Como a pessoa vai descobrir a existência disso? Se a resposta é buscando na loja, você precisa da loja. Se é por link que você mesmo envia, por QR code no balcão ou pelo próprio site, a loja é um obstáculo, não um canal.
  3. Precisa de algo que só o aparelho entrega? Liste os recursos de verdade, não os hipotéticos. A maioria das listas encolhe muito quando alguém pergunta o que é usado toda semana.
  4. Com que frequência isso vai mudar? Produto que muda toda semana sofre com fila de revisão. Produto estável convive bem com ela.

Se as respostas apontam para equipe interna, distribuição por link e mudanças frequentes, o site instalável é quase sempre a escolha certa. Se apontam para consumidor final, descoberta pela busca da loja e recurso de aparelho, o aplicativo se justifica.

O caminho que quase sempre dá certo: começar pelo web

Existe uma ordem que reduz risco e que funciona na maior parte dos projetos que acompanhamos.

Construa primeiro a versão web instalável, com o escopo mínimo que resolve o problema de verdade. Coloque no ar em semanas, não em meses. Use com usuários reais, meça o que eles fazem e descubra quais funções ninguém abre. Depois, se e quando aparecer uma necessidade que só a loja resolve, você já tem o produto validado, a base de dados desenhada e a interface testada, e a versão de loja passa a ser uma etapa de distribuição e não uma aposta.

O contrário costuma sair caro. Começar pelo aplicativo nativo significa investir o orçamento inteiro antes da primeira evidência de uso, e descobrir tarde que metade das telas planejadas não interessava a ninguém.

O que precisa estar pronto antes, independentemente do caminho

Aplicativo, em qualquer formato, é uma casca sobre um sistema. Se o sistema não existe, o aplicativo não tem o que mostrar.

Antes de escolher entre loja e web, a empresa precisa ter os dados em um lugar acessível por integração, uma regra clara sobre quem pode ver o quê, e um endereço próprio para hospedar tudo isso, no domínio da própria empresa. Sem essa base, o projeto vira um aplicativo bonito que precisa de alguém digitando informação manualmente para continuar útil, e isso morre em três meses.

Vale lembrar também do básico de presença: se o objetivo é ser encontrado, o trabalho está no site e na busca, e não na loja de aplicativos. O texto sobre site e busca local cobre esse lado.

Perguntas frequentes

Funciona. O usuário abre o site no navegador do aparelho e usa a opção de adicionar à tela de início. Notificação push também funciona em versões recentes do sistema, com a exigência de que o site tenha sido instalado antes na tela inicial.

Não, porque não há publicação em loja. As contas de desenvolvedor, a fila de revisão e as regras de cobrança dentro do aplicativo simplesmente não se aplicam, já que a distribuição acontece pelo endereço do seu próprio site.

Funciona parcialmente, e isso depende do que foi programado. Ele consegue servir telas e dados guardados no último acesso, e enfileirar ações para enviar quando a conexão voltar. O que ele não faz é buscar informação nova enquanto está sem rede.

Dá, e é uma escolha comum quando o público é misto. O caminho mais econômico é construir a base uma vez, em web, e empacotar essa mesma aplicação para as lojas quando fizer sentido, em vez de manter dois produtos independentes.

Depende do escopo, mas a diferença estrutural é a fila de publicação. Uma correção em site instalável entra no ar no mesmo dia. Em aplicativo de loja, além do desenvolvimento, existe empacotamento, envio e revisão, que pode levar de horas a semanas.

Não há uma resposta única, porque depende de como o usuário chega. Quem procura na busca da loja converte melhor lá. Quem recebe um link, lê um QR code ou já está no seu site converte melhor na versão web, porque cada etapa de instalação perde parte das pessoas.

Nas lojas, venda de conteúdo e assinatura digital costuma ser obrigada a passar pelo sistema de pagamento da plataforma, com a porcentagem correspondente. No site instalável você usa o meio de pagamento que preferir, com as taxas do seu adquirente.

Resumindo

Aplicativo e loja de aplicativo são coisas diferentes, e confundir as duas é o que faz projeto começar caro. Um site instalável entrega ícone na tela, tela cheia, uso sem conexão, notificação e acesso à câmera, sem conta de desenvolvedor, sem fila de revisão e sem porcentagem sobre venda.

A loja continua sendo o caminho certo quando o recurso do aparelho é essencial, quando o produto roda em segundo plano ou quando a busca da loja é como o seu cliente encontra você. Fora disso, ela é um intermediário que cobra em dinheiro, em prazo e em controle.

Se você está avaliando esse tipo de projeto, o passo mais barato é conversar sobre o problema antes de decidir a tecnologia. Fale com a NSWeb e a gente ajuda a separar o que precisa de loja do que já resolve pelo navegador.

Continue lendo

Vamos conversar?

Coloque essas ideias para trabalhar pelo seu negócio

Falar com a NSWEB
Entre em contato

Vamos Conversar? Agende Sua Reunião Online!