Desenvolvimento de aplicativos Android e iOS sob medida.

Que tipo de aplicativo a sua empresa precisa

Quem decide criar um aplicativo para a empresa normalmente tem um desses três casos em mente. Eles parecem iguais na loja, mas pedem decisões técnicas bem diferentes — e confundir um com o outro é o jeito mais comum de gastar dinheiro no lugar errado.

App para o cliente final

Pedido, agendamento, segunda via, acompanhamento de entrega, área do cliente, programa de relacionamento. Aqui a experiência pesa muito: o app concorre com tudo o que a pessoa já tem no celular, precisa ser rápido, bonito e funcionar no aparelho barato de três anos atrás tanto quanto no topo de linha. Também é o tipo em que publicação na App Store e no Google Play, avaliações e atualizações frequentes fazem parte do produto.

App de campo e operação interna

Vendedor externo tirando pedido, técnico fechando ordem de serviço com foto e assinatura, motorista confirmando entrega, inventário com leitor de código de barras, inspeção com checklist. O usuário é da casa e não escolheu o app — ele precisa funcionar sem rede no fundo do galpão, não perder o que foi digitado e sincronizar sozinho quando o sinal voltar. Beleza importa menos; robustez importa mais. Muitas vezes nem precisa estar nas lojas públicas: dá para distribuir de forma privada para os aparelhos da empresa.

App que conversa com o sistema da empresa ou com equipamento

É o app que consulta estoque no ERP, aprova pedido no sistema de gestão, lança apontamento de produção — ou que fala com um dispositivo: balança, impressora térmica, sensor, fechadura, aparelho de automação. Nesse caso o celular é a ponta de um sistema maior, e o trabalho de verdade está na integração. A NasteSoft tem experiência com o SDK da Tuya para aplicativos IoT, com pareamento, Bluetooth e controle de dispositivos — detalhamos esse trabalho na página de integração Tuya.

Nativo, multiplataforma ou casca web

É a primeira pergunta que costuma aparecer, e a resposta honesta é que as três opções são boas em situações diferentes. O que decide não é preferência do fornecedor: é o que o app precisa fazer, quanto do sistema já existe e quem vai manter o código depois.

Flutter e React Native amadureceram a ponto de serem a escolha padrão para aplicativo sob medida de empresa. Entre os dois, pesa o que a equipe que vai herdar o código conhece: React Native aproveita quem já trabalha com JavaScript e TypeScript; Flutter usa Dart e controla a renderização da interface por conta própria, o que dá consistência visual entre as plataformas. Nenhum dos dois é errado para um app de negócio.

O nativo continua sendo a resposta certa quando o app é, no fundo, um controle remoto de hardware, ou quando o fabricante entrega o SDK apenas para Android e iOS nativos. E a casca web é legítima quando o sistema web já resolve bem o problema — o erro é achar que ela dispensa o resto do trabalho.

O que um app precisa além das telas

As telas são a parte visível e, em geral, a menor parte do desenvolvimento mobile. O que separa um app que dura de um que vira problema é o que está em volta delas.

• API. O app nunca acessa o banco de dados direto. Ele conversa com uma API que autentica, valida, aplica a regra de negócio e devolve só o que aquele usuário pode ver. Se a API não existe, ela entra no escopo — e costuma ser a maior parte dele.
• Login e sessão. Login que não pede senha a cada abertura, biometria, renovação de token, revogação quando o funcionário sai da empresa ou o aparelho é perdido.
• Notificações push. Via Firebase Cloud Messaging no Android e APNs no iOS, com um serviço do lado do servidor que decide quem recebe o quê. Push mal calibrado é desinstalação.
• Offline. Decidir o que funciona sem rede, guardar localmente, sincronizar depois e resolver conflito quando duas pessoas mexeram no mesmo registro. Em app de campo, é requisito, não opcional.
• Publicação nas lojas. Contas de desenvolvedor em nome da sua empresa, política de privacidade, declaração de dados coletados, telas e textos da loja, revisão da Apple e do Google, e um processo para publicar atualizações sem susto.
• Versão mínima e atualização forçada. Quando a API muda, o app antigo que ficou no celular de alguém continua chamando a versão velha. É preciso prever compatibilidade e um mecanismo para exigir atualização.
• Monitoramento. Relatório de falhas e métricas de uso, para saber que o app travou num modelo de aparelho antes que o cliente reclame.

Manutenção quando o sistema muda

Aplicativo não é entrega única. Android e iOS ganham versão nova todo ano, as lojas atualizam as exigências de publicação, bibliotecas ficam obsoletas e, principalmente, o sistema da empresa muda: um campo novo no cadastro, uma regra fiscal, um fluxo de aprovação diferente. Com a regra de negócio na API, boa parte dessas mudanças acontece só no servidor, sem publicar app novo. É uma decisão de arquitetura que paga a conta da manutenção por anos.

App como porta de saída do sistema legado

Muita empresa chega até nós com um pedido que parece simples: "queremos o nosso sistema no celular". O sistema é um desktop em Delphi, VB6 ou .NET Framework, com a regra de negócio dentro dos eventos das telas e o banco acessado direto de cada formulário. Não há o que o app possa chamar.

É aqui que o aplicativo e a migração de sistemas legados se encontram. Para o app existir, alguém precisa entender o que o sistema antigo faz, documentar as regras e reescrevê-las numa API. Essa API é exatamente o primeiro pedaço de uma migração incremental: o app passa a consumi-la enquanto o desktop continua rodando, e cada nova funcionalidade movida para a API serve aos dois — e, mais tarde, ao sistema web que substituirá o desktop.

Não usamos conversor automático e não ligamos o celular direto no banco do legado. Primeiro entendemos e documentamos; depois escrevemos o código na arquitetura certa. Explicamos esse caminho, do sistema desktop ao aplicativo, neste artigo.

Como o projeto acontece

1. Levantamento. Quem vai usar, em que situação, com que aparelho e com que rede. Que sistema já existe, onde estão os dados e o que a API precisa expor. Às vezes a conclusão é que um sistema web responsivo resolve — e dizemos isso.
2. Primeiro caso de uso. Escolhemos a tarefa que mais gera valor e cabe numa primeira entrega: tirar pedido, fechar ordem de serviço, consultar saldo. Não o sistema inteiro.
3. Arquitetura e tecnologia. Nativo, multiplataforma ou casca; desenho da API; autenticação; estratégia offline; contas nas lojas em nome da empresa.
4. Construção em ciclos curtos. Versões de teste instaláveis nos aparelhos de quem vai usar, a cada poucas semanas, para corrigir o rumo com uso real — não com protótipo em slide.
5. Publicação. Preparação da loja, revisão da Apple e do Google, ou distribuição privada para apps internos.
6. Evolução e manutenção. Novos casos de uso, atualizações de plataforma, monitoramento de falhas. Código, documentação e contas ficam com a sua empresa.

O mesmo time que desenha a API escreve o app. Para quem precisa também do sistema web ou desktop por trás, o trabalho segue na frente de desenvolvimento de software sob medida.

Perguntas frequentes