Desenvolvimento de aplicativo mobile com Flutter
Uma base de código pro iOS e pro Android, publicada nas lojas. Inclusive quando o app precisa falar com hardware e continuar funcionando sem sinal.
A App.co desenvolve aplicativo multiplataforma em Flutter: uma base de código em Dart que roda no iOS e no Android e que, quando o projeto pede, também vira dashboard web. A gente cobre o ciclo inteiro: design das telas, arquitetura, integração com o backend, publicação na App Store e na Google Play e assinatura recorrente dentro do app.
Dois cases publicados mostram até onde isso vai. No Farm Tracker, o app conversa com o hardware do cliente por Bluetooth e registra a operação inteira sem internet. No ALLTURISMO, o app foi aprovado nas duas lojas com assinatura recorrente rodando. É esse tipo de app que a gente constrói: o que tem que aguentar a operação real do cliente.
O que entra no desenvolvimento de um app?
A gente combina o escopo da primeira versão antes de escrever a primeira linha: o que entra, o que fica pra depois e o que cada corte desses muda no prazo. Daí em diante você acompanha cada etapa, sem letra miúda.
- Arquitetura do produto: o que roda no dispositivo, o que roda no backend e o que vem do hardware.
- Design das telas e interface em Flutter. Se você já tem identidade visual ou protótipo, a gente parte dele; se não tem, a gente desenha junto.
- Integração com a API, com serviços externos e com o que o cliente já usa.
- Publicação na App Store e na Google Play, com o que cada loja cobra na revisão.
- Assinatura e compra dentro do app, quando o modelo de negócio é esse.
- Evolução depois do lançamento. A gente entrega e fica por perto depois.
Por que Flutter, e quando ele não é a resposta?
Flutter deixa uma equipe pequena manter iOS e Android sem escrever o produto duas vezes. É uma base só, em Dart, e o comportamento fica igual nas duas plataformas porque quem desenha a tela é o próprio framework.
No Farm Tracker isso foi longe: a mesma base Flutter serviu o app que vai pro campo e o dashboard web que o gestor abre no escritório. Um código, duas situações de uso muito diferentes.
Flutter não é resposta pra tudo. Quando o produto vive de um recurso muito específico de uma plataforma só, ou de um SDK que o fabricante só publica em nativo, o multiplataforma vira remendo. A gente fala isso na conversa de escopo, não no meio do projeto, mesmo quando a resposta honesta é que o projeto não é pra gente.
Como a mesma base Flutter virou app de campo e dashboard no Farm TrackerE se o app precisar funcionar sem internet?
Tem operação que acontece onde não chega sinal. Lavoura é o caso clássico: o trator entra no talhão e o celular fica sem rede o resto do dia. Um app que depende de conexão pra registrar simplesmente não serve.
A saída é arquitetura offline-first. O app grava tudo no dispositivo e trata a sincronização como um evento à parte, que acontece quando a rede volta. Não é ligar um cache: é decidir, desde o modelo de dados, quem é a fonte da verdade e o que fazer quando as duas pontas mudaram enquanto estavam separadas.
No Farm Tracker o rastreio da aplicação de insumos segue rodando sem rede e sincroniza assim que o app detecta sinal.
E se o app tiver que falar com um equipamento?
Bluetooth Low Energy é o caminho mais comum quando o app precisa conversar com um equipamento. É também onde a maioria dos projetos trava, porque aí o app deixa de ser tela e vira parte da operação: se o pareamento cai no meio do serviço, alguém no campo perde o trabalho do dia.
O Farm Tracker é exatamente isso. O cliente já tinha um hardware proprietário com GPS e RFID, feito pra ficar acoplado ao trator durante a aplicação de insumos. O que faltava era a camada de software: o app em Flutter lendo o hardware por Bluetooth, o dashboard pro gestor e uma API em C# / .NET sobre PostgreSQL costurando as pontas. A App.co entrou nesse projeto em parceria com a Bitzen.
Ver o case de integração com hardware do Farm TrackerQuem cuida da publicação na App Store e na Google Play?
A gente. Publicar não é subir arquivo: é ficha do app, política de privacidade, permissão justificada uma por uma, build assinado e a revisão de cada loja, que reprova por motivos diferentes e no tempo delas.
O app do ALLTURISMO foi aprovado na App Store e na Google Play, e ficou disponível pro turista que chega em Florianópolis.
Dá pra cobrar assinatura dentro do app?
Dá, e é onde mais projeto se enrola. Apple e Google exigem que a compra de conteúdo digital passe pela loja, cada uma com seu ciclo de renovação, cancelamento e reembolso. Fazer isso duas vezes, uma pra cada plataforma, é trabalho dobrado e bug dobrado.
No ALLTURISMO a assinatura recorrente foi integrada via RevenueCat e ficou ativa no iOS e no Android. Uma camada só cuidando dos dois lados, em vez de duas implementações pra manter.
Ver as quatro pontas do produto no case ALLTURISMOQuem vai tocar o seu projeto?
A App.co foi fundada em 2025 por dois sócios, e são os dois que tocam o trabalho. Gustavo Arcolezi é mestre em Física, desenvolvedor Flutter e professor de Programação para Dispositivos Móveis na UNICIVE, em Maringá. Antonio Almeida é formado em Análise e Desenvolvimento de Sistemas e cuida de arquitetura, code review e escolha de stack, com backend em .NET e Node.js.
Em parte dos projetos a App.co trabalha junto com a Bitzen, como no Farm Tracker e no Agrária Ortssippenbuch.
Conhecer quem está por trás da App.coA prova
Onde esse serviço já rodou
Farm Tracker
App em Flutter conversando por Bluetooth com o hardware de GPS e RFID acoplado ao trator, camada offline-first pro rastreio seguir sem rede, dashboard em Flutter Web e API em C# / .NET sobre PostgreSQL.
Ver o case completoALLTURISMO
App em Flutter aprovado na App Store e na Google Play, com catálogo de restaurantes, ativação de cupom e assinatura recorrente via RevenueCat nas duas lojas.
Ver o case completoStack
O que a gente usa aqui
App
Hardware
Backend
Lojas & assinatura
Dúvidas
Perguntas que sempre aparecem
Em quanto tempo um aplicativo fica pronto?
Uma primeira versão enxuta, com as telas essenciais e publicação nas lojas, costuma levar de 6 a 12 semanas. Um app médio, com backend próprio e painel administrativo, fica entre 3 e 5 meses. Quando entra integração com equipamento ou operação offline, o intervalo vai pra 4 a 6 meses, porque parte do trabalho é testar em campo, não só programar. Antes de combinar prazo a gente quebra a primeira versão em etapas e estima uma por uma — o número que vale é o do seu escopo, não a média.
Depois que o app fica pronto, quanto tempo até estar na loja?
Conte com até 30 dias entre o build finalizado e o app disponível pra baixar. A revisão da App Store e da Google Play tem tempo próprio, cada uma reprova por motivos diferentes, e a primeira submissão de uma conta costuma demorar mais que as seguintes. Esse prazo entra no cronograma desde o começo, não como surpresa no fim.
O mesmo app funciona no iPhone e no Android?
Funciona. Flutter gera o app pras duas plataformas a partir de uma base de código em Dart, e a publicação é feita nas duas lojas. Foi assim no ALLTURISMO, aprovado na App Store e na Google Play.
Flutter serve pra web também?
Serve, e às vezes é a melhor escolha: no Farm Tracker o dashboard do gestor é Flutter Web, com a mesma base do app de campo. Não é o caminho pra todo produto web. Quando o projeto é uma plataforma de conteúdo ou um sistema administrativo grande, a gente usa SvelteKit, React ou Angular.
O app pode conversar com um equipamento que a gente já usa?
Pode, e é uma das coisas que a App.co já entregou no Farm Tracker. O que muda de projeto pra projeto é o protocolo do equipamento e o que ele deixa o app ver: o que dá pra ler, o que dá pra escrever e com que frequência ele responde. Antes de prometer prazo a gente olha a documentação do fabricante ou testa o equipamento na mão.
Tem um app pra tirar do papel?
Conta o que precisa. A gente responde rápido e fala reto.
Falar no WhatsAppOu por e-mail: gustavo@app-co.net