As bibliotecas Shiny — Bluetooth, tarefas em segundo plano, push, localização e sincronização para .NET — já passaram de 40 milhões de downloads e estão no arquivo de projeto de apps que você conhece. Nós as escrevemos, nós as mantemos e trabalhamos com a equipe do .NET MAUI na Microsoft. Quando seu app precisa funcionar em dispositivos reais, em campo, é essa a profundidade que você está contratando.
O lado dos dispositivos do negócio, construído sobre uma base que já está em produção.
Apps .NET MAUI, iOS e Android em produção e conversões de Xamarin → MAUI — incluindo o trabalho de segundo plano, offline e ciclo de vida que a maioria das equipes erra. Trabalhamos com a equipe do .NET MAUI na Microsoft desde o início do MAUI.
BLE central e periférico, frotas de dispositivos e integração com hardware. Escrevemos as bibliotecas que o mercado usa para isso.
Rastreamento de localização, geofencing e telemetria para veículos e equipes que trabalham onde a conectividade não é garantida.
Apps para Apple Watch, Wear OS, CarPlay e Android Auto que levam seu app móvel ao pulso e ao painel do carro, pensados para uma olhada rápida ou um comando de voz, não para uma tela de celular encolhida. A conexão entre o celular e o relógio roda sobre uma biblioteca que nós escrevemos.
Um orçamento compra meses de engenharia. A questão é em que esses meses são gastos. Em um produto conectado — qualquer coisa com um dispositivo, um processo em segundo plano ou uma necessidade de funcionar offline — boa parte do primeiro ano vai para uma infraestrutura que não tem valor visível para o cliente e que milhares de equipes já escreveram antes.
Proporções ilustrativas — a divisão exata depende do projeto. O que não muda é de que lado da linha está aquilo que você paga uma equipe de engenharia para reconstruir.
Receita e feedback chegam antes, porque o cronograma não começa com um trimestre de trabalho de base.
Os subsistemas mais arriscados — trabalho em segundo plano, sincronização, conectividade com dispositivos — já estão comprovados em produção antes do seu projeto começar.
Menos código que é só seu significa menos para corrigir, portar e manter equipe para isso, ano após ano depois da entrega.
O vértice que a maioria dos projetos sacrifica é um que nós já pagamos, às claras, ao longo de 25 anos — e ele vem junto com o projeto. O que isso compra para você é simples: mais do ano vai para o produto que você se propôs a construir, e menos para chegar à linha de largada.
Todo projeto pode começar por uma destas. Cada uma tem um nome e um escopo registrado por escrito antes de começarmos, para que a primeira decisão seja pequena — e você veja como trabalhamos antes de se comprometer com algo maior.
Para apps que já estão no .NET MAUI — tempo de inicialização, falhas que só se reproduzem em dispositivos reais e trabalho em segundo plano que parou de disparar depois de uma atualização do sistema.
Uma lista ordenada de correções, com as piores diagnosticadas até a linha de código.
Cada plugin e dependência de plataforma do seu app Xamarin mapeados para o que os substitui no .NET MAUI — a etapa em que a maioria das migrações empaca.
Um plano de migração construído a partir de uma consulta, e não de uma fase de pesquisa — e uma estimativa real.
Seu hardware conversando com um app real no iOS e no Android — buscando, conectando, reconectando e sincronizando em segundo plano, em dispositivos, não em um simulador.
A prova de que a parte difícil funciona em celulares reais, e um caminho orçado até o app de produção.
Toda oferta é orçada a preço fechado depois de conhecermos o escopo — e um preço fechado não muda: se levarmos mais tempo, o problema é nosso, não seu.
A conversão da interface raramente é o que decide — é a lista de dependências. A auditoria de dependências de duas semanas mapeia cada plugin para o seu substituto e transforma isso em uma estimativa em fases.
Não. Geralmente faz sentido, porque elas são open source, já estão em produção e são mantidas por quem está fazendo o trabalho. Você nunca fica preso a uma camada privada que só o fornecedor entende.
Sim. A maioria dos problemas de Bluetooth aparece na fronteira entre o app e o firmware, e estamos acostumados a trabalhar dos dois lados dela — inclusive dizendo a um fornecedor o que precisa mudar do lado dele.
Nossa profundidade está no .NET MAUI e no .NET para iOS e Android, incluindo o código de plataforma nativo por baixo deles. Se um app nativo for a escolha certa para o seu produto, vamos dizer isso.
Conte sobre o app, os dispositivos e onde eles são usados. Diremos onde isso costuma dar errado — e como evitaríamos.
