La mayor parte del trabajo móvil B2B no se trata de una app que los usuarios descargan de la tienda. Se trata de una app complementaria que se acopla a una tienda y a un ERP, entregada a una flota de dispositivos conocida (representantes de ventas, personal de almacén, conductores), que hace las cosas que los navegadores de escritorio hacen mal. Este es el patrón que se ha sostenido a lo largo de nuestros desarrollos recientes en .NET MAUI.
Tres patrones de app complementaria que entregamos
1. App complementaria para representantes de ventas
El representante visita a un cliente, abre la app y tiene frente a él el historial de pedidos del cliente, los precios contratados, el inventario disponible y las facturas recientes. Puede colocar un pedido en nombre del cliente (el patrón de "suplantación" de B2B Edition, aplicado al móvil). La app se acopla a la misma tienda B2B que usaría el cliente; el representante tiene permisos elevados.
2. App complementaria para almacén
Los surtidores y empacadores escanean códigos de barras, ven listas de surtido y confirman envíos. A diferencia de una app para representantes, la app de almacén tiene restricciones de hardware: lectores Android resistentes, a menudo sin LTE dentro del almacén y, a veces, integración de surtido por voz.
3. App complementaria para servicio en campo
Los técnicos de servicio ven los trabajos asignados, el historial del cliente, las refacciones en el camión y las fotos de visitas anteriores. Suelen ser de tipo offline-first, porque están en sótanos, áticos y sitios de trabajo rurales sin señal.
Lo que MAUI aporta
- Una sola base de código en iOS, Android y Windows. El representante recibe la app de iPhone. El almacén usa lectores Android. Operaciones usa tabletas Windows. El mismo código.
- Rendimiento nativo. A diferencia de React Native o Flutter (ambas buenas opciones para algunos equipos), las apps de MAUI compilan a binarios nativos con controles de interfaz nativos. Las listas se desplazan con fluidez con miles de elementos, algo que importa en apps con catálogos extensos.
- El ecosistema .NET. Si tu backend es .NET (ASP.NET Core, EF Core, Azure Functions), compartir modelos, reglas de validación y serialización entre el móvil y el servidor es una ganancia real de productividad.
- El compromiso de Microsoft. Xamarin está descontinuado; MAUI es su sucesor con inversión activa. Para una app de más de 5 años, eso importa.
En qué difieren los patrones móviles B2B respecto a B2C
Autenticación
El móvil B2C usa inicio de sesión social o usuario/contraseña. El móvil B2B usa identidad corporativa: Azure AD / Entra ID, Okta, a veces un IdP propio. El patrón móvil de primera clase es OIDC / OAuth2 con PKCE, con una renovación de tokens adecuada y una ruta de reautenticación limpia cuando los tokens caducan a mitad de la sesión. SAML aún aparece en stacks empresariales, pero en el móvil tiene que entrar mediante un flujo basado en navegador o en broker (navegador del sistema, ASWebAuthenticationSession, AppAuth), no con una librería SAML nativa. Usamos MSAL.NET para apps basadas en AAD; es maduro y maneja bien los casos límite.
Offline-first
Las apps B2C dan por hecha la conectividad. Las apps B2B de campo no. El patrón que funciona:
- SQLite (vía sqlite-net-pcl) como almacén local
- Una capa de sincronización que registra "acciones previstas" mientras está sin conexión (colocar un pedido, marcar un trabajo como terminado, capturar una firma) y las reproduce al reconectarse
- Una resolución de conflictos explícita, no silenciosa: si el mismo cliente se editó en línea y sin conexión, muéstrale el conflicto al usuario
- Marcas de tiempo de última modificación desde el servidor para que la resincronización solo traiga los deltas
Notificaciones push
El push B2C es para marketing. El push B2B es operativo: "cambió la asignación de tu trabajo", "regresó una cotización de un cliente", "alerta de inventario bajo en un SKU que seguías". Mantenlas escasas y de alta señal; los usuarios con tres push operativos al día dejan de leerlos cuando uno es "grandes ofertas en...".
Integración de hardware
Escaneo de códigos de barras, NFC, captura de firma, captura de foto con metadatos, BLE para conectarse a impresoras o básculas de etiquetas: todo esto requiere manejadores específicos de cada plataforma. La arquitectura de manejadores de MAUI es buena para esto; presupuesta tiempo para ello.
La arquitectura que usamos
Para la mayoría de las apps complementarias:
- MVVM con CommunityToolkit.Mvvm para el código repetitivo (RelayCommand, generadores de origen de ObservableProperty)
- Shell para la navegación si es una app nueva (basada en URL, menú lateral gratuito, búsqueda)
- Refit para clientes REST tipados hacia el backend de ASP.NET Core
- Polly para reintentos/cortacircuitos en conexiones inestables
- Serilog escribiendo a un archivo local y volcando al servidor cuando hay conexión: cuando un representante dice "mi app se cayó ayer", los registros están ahí
- Reportes de fallos y diagnóstico vía Firebase Crashlytics, Sentry, Bugsnag o Azure Monitor: elige uno según el resto del stack de observabilidad del cliente. (Microsoft descontinuó la mayor parte de App Center después del 2025-03-31; el soporte de Analytics y Diagnostics solo llega hasta 2027, así que no lo especificamos para proyectos nuevos.)
- Distribución vía TestFlight / los canales interno y cerrado de Google Play para despliegues escalonados, y MDM (Intune, Jamf, Workspace ONE) para builds empresariales o de distribución privada. Evita los patrones de "parche en caliente" OTA, ya que violan la política de tienda de Apple.
Qué se vuelve más difícil en MAUI frente a lo nativo
Cosas honestas que conviene prever:
- Los controles de plataforma personalizados dan más trabajo que en nativo: los manejadores de MAUI son buenos, pero verbosos. Si tu diseño tiene muchos requisitos de precisión al píxel, asigna tiempo.
- Las API nativas profundas (peculiaridades específicas de BLE, comportamientos particulares de la cámara) a veces requieren código específico de plataforma. Eso es normal en multiplataforma; presupuéstalo.
- La distribución en iOS sigue requiriendo una cuenta de Apple Developer, perfiles de aprovisionamiento y todo el baile de certificados, incluso para B2B empresarial. Microsoft no ha facilitado eso.
La conclusión
Las apps móviles complementarias B2B son de las más usadas y menos vistosas de nuestro portafolio. Viven en los dispositivos durante años, corren junto a la tienda y al ERP, y son donde la productividad del representante de verdad se acumula. .NET MAUI es la herramienta adecuada cuando tu backend es .NET y tu diseño tolera una interfaz con sensación nativa; los patrones de arriba son los que usamos para mantenerlas mantenibles más allá del lanzamiento.
¿Estás dimensionando un proyecto de app complementaria? Cuéntanos sobre la flota de dispositivos y el flujo de trabajo con el que se acopla: así es como estimamos con honestidad en lugar de partir de una plantilla genérica.