A maior parte do trabalho mobile B2B não é sobre um app que os usuários baixam da loja. É sobre um app complementar que se integra a uma loja e a um ERP, entregue a uma frota de dispositivos conhecida (representantes de vendas, equipe de almoxarifado, motoristas), que faz aquilo que os navegadores de desktop fazem mal. Este é o padrão que se sustentou ao longo dos nossos projetos recentes em .NET MAUI.
Três padrões de app complementar que entregamos
1. App complementar para representantes de vendas
O representante visita um cliente, abre o app e tem diante de si o histórico de pedidos do cliente, os preços contratados, o estoque disponível e as faturas recentes. Pode lançar um pedido em nome do cliente (o padrão de "personificação" do B2B Edition, aplicado ao mobile). O app se integra à mesma loja B2B que o cliente usaria; o representante tem permissões elevadas.
2. App complementar para almoxarifado
Separadores e embaladores leem códigos de barras, veem listas de separação e confirmam expedições. Diferente de um app para representantes, o app de almoxarifado tem restrições de hardware: coletores Android robustos, frequentemente sem LTE dentro do galpão e, às vezes, integração com separação por voz.
3. App complementar para serviço em campo
Os técnicos de serviço veem as ordens atribuídas, o histórico do cliente, as peças no caminhão e as fotos de visitas anteriores. Costumam ser offline-first, pois estão em porões, sótãos e locais de trabalho rurais sem sinal.
O que o MAUI traz
- Uma única base de código em iOS, Android e Windows. O representante recebe o app de iPhone. O almoxarifado usa coletores Android. As operações usam tablets Windows. O mesmo código.
- Desempenho nativo. Diferente do React Native ou do Flutter (ambas boas escolhas para alguns times), os apps MAUI compilam para binários nativos com controles de interface nativos. As listas rolam com fluidez mesmo com milhares de itens, o que importa em apps com catálogos extensos.
- O ecossistema .NET. Se o seu backend é .NET (ASP.NET Core, EF Core, Azure Functions), compartilhar modelos, regras de validação e serialização entre o mobile e o servidor é um ganho real de produtividade.
- O compromisso da Microsoft. O Xamarin foi descontinuado; o MAUI é o sucessor, com investimento ativo. Para um app de mais de 5 anos, isso importa.
Em que os padrões mobile B2B diferem do B2C
Autenticação
O mobile B2C usa login social ou usuário/senha. O mobile B2B usa identidade corporativa: Azure AD / Entra ID, Okta, às vezes um IdP próprio. O padrão mobile de primeira classe é OIDC / OAuth2 com PKCE, com renovação de tokens adequada e um caminho de reautenticação limpo quando os tokens expiram no meio da sessão. O SAML ainda aparece em stacks corporativos, mas no mobile precisa entrar por um fluxo baseado em navegador ou em broker (navegador do sistema, ASWebAuthenticationSession, AppAuth), e não por uma biblioteca SAML nativa. Usamos o MSAL.NET para apps baseados em AAD; é maduro e lida bem com os casos extremos.
Offline-first
Os apps B2C presumem conectividade. Os apps B2B de campo não. O padrão que funciona:
- SQLite (via sqlite-net-pcl) como armazenamento local
- Uma camada de sincronização que registra "ações pretendidas" enquanto está offline (lançar pedido, marcar serviço como concluído, capturar assinatura) e as reproduz ao reconectar
- Uma resolução de conflitos explícita, não silenciosa: se o mesmo cliente foi editado online e offline, mostre o conflito ao usuário
- Marcas de tempo de última modificação vindas do servidor, para que a ressincronização traga apenas os deltas
Notificações push
O push B2C é para marketing. O push B2B é operacional: "a atribuição do seu serviço mudou", "voltou uma cotação de um cliente", "alerta de estoque baixo em um SKU que você acompanhava". Mantenha-as escassas e de alto sinal; usuários com três pushes operacionais por dia param de lê-los quando um deles é "grandes ofertas em...".
Integração de hardware
Leitura de código de barras, NFC, captura de assinatura, captura de foto com metadados, BLE para conectar a impressoras ou balanças de etiquetas: tudo isso exige handlers específicos de cada plataforma. A arquitetura de handlers do MAUI é boa para isso; reserve tempo para ela.
A arquitetura que usamos
Para a maioria dos apps complementares:
- MVVM com o CommunityToolkit.Mvvm para o código repetitivo (RelayCommand, geradores de origem de ObservableProperty)
- Shell para a navegação, se for um app novo (baseado em URL, menu lateral gratuito, busca)
- Refit para clientes REST tipados em direção ao backend ASP.NET Core
- Polly para repetição/disjuntor em conexões instáveis
- Serilog gravando em arquivo local e descarregando no servidor quando há conexão: quando um representante diz "meu app travou ontem", os logs estão lá
- Relatórios de falha e diagnóstico via Firebase Crashlytics, Sentry, Bugsnag ou Azure Monitor: escolha um conforme o restante do stack de observabilidade do cliente. (A Microsoft descontinuou a maior parte do App Center depois de 2025-03-31; o suporte de Analytics e Diagnostics vai apenas até 2027, então não o especificamos para projetos novos.)
- Distribuição via TestFlight / trilhas interna e fechada da Google Play para lançamentos escalonados, e MDM (Intune, Jamf, Workspace ONE) para builds corporativos ou de distribuição privada. Evite padrões de "correção a quente" via OTA, pois eles violam a política de loja da Apple.
O que fica mais difícil no MAUI em relação ao nativo
Coisas honestas para planejar:
- Controles de plataforma personalizados dão mais trabalho do que no nativo: os handlers do MAUI são bons, mas verbosos. Se o seu design tem muitos requisitos de precisão ao pixel, reserve tempo.
- APIs nativas profundas (peculiaridades específicas de BLE, comportamentos particulares da câmera) às vezes exigem código específico de plataforma. Isso é normal no multiplataforma; inclua no orçamento.
- A distribuição no iOS ainda exige uma conta Apple Developer, perfis de provisionamento e toda a dança de certificados, mesmo para B2B corporativo. A Microsoft não tornou isso mais fácil.
A conclusão
Os apps móveis complementares B2B estão entre os softwares mais usados e menos vistosos do nosso portfólio. Vivem nos dispositivos por anos, rodam ao lado da loja e do ERP, e são onde a produtividade do representante de fato se acumula. O .NET MAUI é a ferramenta certa quando o seu backend é .NET e o seu design tolera uma interface com toque nativo; os padrões acima são o que usamos para mantê-los sustentáveis depois do lançamento.
Está dimensionando um projeto de app complementar? Conte para nós sobre a frota de dispositivos e o fluxo de trabalho ao qual ele se integra: é assim que estimamos com honestidade, em vez de partir de um modelo genérico.