Quando construir app desktop em vez de web

A web é um ambiente incrivelmente poderoso. Com Next.js, React, APIs modernas do browser e uma boa CDN, é possível construir aplicações sofisticadas que rodam em qualquer dispositivo com um navegador. Para a esmagadora maioria dos casos de uso — dashboards, e-commerces, plataformas SaaS, sistemas de gestão — uma web app bem construída é mais barata, mais fácil de atualizar e mais acessível do que um app desktop.

Mas existe um conjunto específico de requisitos onde a web simplesmente não consegue entregar o que o negócio precisa. Quando você se depara com esses requisitos, tentar forçar uma solução web geralmente resulta em hacks, workarounds frágeis, experiência de usuário degradada — e eventualmente na necessidade de reescrever tudo como app desktop de qualquer forma.

Entender quando o desktop é a escolha correta poupa meses de desenvolvimento e retrabalho. Estes são os critérios técnicos que determinam essa decisão.

Acesso a Hardware: Câmera, Impressora e Periféricos Industriais

O browser tem APIs de hardware. A MediaDevices API permite acesso à câmera e microfone. A Web USB API permite comunicação com alguns dispositivos USB. A Web Serial API foi adicionada ao Chrome e permite comunicação serial em alguns casos.

O problema é que essas APIs são limitadas por design — e por boas razões de segurança. O browser roda em um ambiente sandboxed que deliberadamente impede acesso irrestrito ao hardware. Para uso geral, isso é ótimo. Para aplicações que precisam de controle preciso de hardware, é um obstáculo sério.

Considere um sistema de controle de estoque que precisa se comunicar com uma balança industrial via RS232. A Web Serial API pode funcionar em teoria, mas depende de permissões do usuário a cada sessão, pode ter comportamento inconsistente entre atualizações do Chrome, e não oferece controle sobre parâmetros de comunicação como baud rate, bits de parada e paridade com a mesma confiabilidade de uma biblioteca nativa.

Com um app desktop usando Electron e a biblioteca serialport, a comunicação é direta, estável e completamente controlável. O mesmo vale para impressoras fiscais, leitores de código de barras industriais, controladores PLC, balanças de precisão e qualquer dispositivo que se comunique via protocolos seriais ou USB com drivers específicos.

Se o sistema precisa se comunicar de forma confiável com hardware especializado, a web vai criar mais problemas do que soluções.

Performance Offline: Dados Locais sem Latência de Rede

Progressive Web Apps podem funcionar offline via Service Workers. Para apps de leitura, formulários simples ou conteúdo em cache, isso é suficiente. Mas há uma diferença fundamental entre "funcionar de forma degradada sem internet" e "ser projetado para operar primariamente de forma local".

Ambientes industriais frequentemente têm conectividade intermitente ou inexistente: fábricas com infraestrutura de rede precária, armazéns com pontos cegos de Wi-Fi, obras em campo, embarcações, mineradoras em locais remotos. Para esses cenários, o modelo mental correto não é "sincroniza com a nuvem e tem fallback offline" — é "funciona localmente e sincroniza quando tem rede disponível".

Um app desktop com SQLite local tem latência de consulta na casa dos microsegundos. Operações que envolveriam uma requisição HTTP com latência de 50 ms a 300 ms acontecem instantaneamente. Para sistemas onde operadores fazem centenas de operações por hora — registro de produção, inspeção de qualidade, controle de movimentação — essa diferença de performance é perceptível e impacta diretamente a produtividade.

Além disso, com dados locais não há dependência de disponibilidade de servidor. Uma queda de conectividade não para as operações. Uma falha de servidor não afeta os operadores no chão de fábrica. O app simplesmente continua funcionando.

Segurança Local: Dados que Não Podem Ir para a Nuvem

Nem todo dado pode ou deve trafegar pela internet. Existem cenários onde regulamentação, contratos ou simplesmente política interna exigem que os dados permaneçam dentro da infraestrutura local da empresa — ou dentro da própria máquina do usuário.

Consultórios médicos com dados de pacientes sujeitos a regulamentações de privacidade. Escritórios de advocacia com documentos sigilosos de clientes. Empresas de defesa e governo com restrições de confidencialidade. Indústrias com propriedade intelectual sensível que não pode sair da rede interna. Todos esses casos têm em comum a necessidade de controle sobre onde os dados ficam armazenados.

Um app desktop com banco de dados local criptografado — como SQLite com SQLCipher — mantém os dados na máquina ou na rede local. Não há tráfego para servidores externos. Não há risco de vazamento por falha de segurança em um servidor remoto. O controle sobre os dados é completo e auditável.

Isso é fundamentalmente diferente de uma web app, mesmo uma hospedada em servidor próprio da empresa, porque o modelo de acesso e os vetores de ataque são diferentes.

Integração com OS: Notificações, Tray Icon e File System

Aplicações que precisam de integração profunda com o sistema operacional — além do que o browser oferece — são candidatas naturais ao desktop.

Exemplos concretos de integrações que web apps não conseguem replicar de forma nativa:

// Electron: ícone na bandeja do sistema com menu de contexto
const { Tray, Menu, nativeImage } = require('electron')

const tray = new Tray(nativeImage.createFromPath('./icon.png'))
const contextMenu = Menu.buildFromTemplate([
  { label: 'Abrir Dashboard', click: () => mainWindow.show() },
  { label: 'Sincronizar Agora', click: () => syncData() },
  { type: 'separator' },
  { label: 'Sair', role: 'quit' }
])
tray.setContextMenu(contextMenu)
tray.setToolTip('Sistema de Monitoramento — Online')

Notificações nativas do sistema operacional (não as do browser), atalhos de teclado globais que funcionam mesmo quando o app está minimizado, acesso irrestrito ao sistema de arquivos para leitura e escrita de diretórios arbitrários, integração com protocolos customizados de URL (myapp://), drag-and-drop de arquivos com acesso ao caminho completo, execução de processos externos — todas essas integrações são nativas no Electron ou Tauri e difíceis ou impossíveis em uma web app.

Se a aplicação precisa "viver" no sistema operacional — estar disponível em background, reagir a eventos do sistema, manipular arquivos de forma extensiva — o desktop é o ambiente correto.

Conclusão com CTA

A decisão entre desktop e web não é uma questão de tecnologia favorita ou familiaridade da equipe. É uma questão de requisitos. Web apps são mais rápidas de desenvolver, mais fáceis de distribuir e atualizar, e cobrem a maioria dos casos de uso de software empresarial moderno.

Mas quando o sistema precisa de acesso confiável a hardware especializado, performance garantida sem dependência de rede, controle total sobre onde os dados ficam armazenados, ou integração profunda com o sistema operacional — o app desktop não é uma opção nostálgica. É a escolha tecnicamente correta.

Na SystemForge, construímos aplicações desktop para exatamente esses casos: sistemas industriais, ferramentas de gestão para ambientes com conectividade limitada, aplicações com requisitos rígidos de segurança de dados. Se você está mapeando os requisitos de um sistema e não tem certeza se desktop ou web é a decisão certa, podemos ajudar nessa análise antes de qualquer linha de código.