Most B2B mobile work isn’t about an app users download from the store. It’s about a companion app that pairs with a storefront and an ERP — handed to a known device fleet (sales reps, warehouse staff, drivers) — that does the things desktop browsers do badly. Here’s the pattern that’s held up across our recent .NET MAUI builds.
Three companion-app patterns we ship
1. Sales-rep companion
The rep visits a customer, opens the app, has the customer’s order history, contracted prices, available inventory, and recent invoices in front of them. Can place an order on behalf of the customer (B2B Edition’s "masquerade" pattern, applied to mobile). The app pairs with the same B2B storefront the customer would use; the rep has elevated permissions.
2. Warehouse companion
Pickers and packers scan barcodes, see pick lists, confirm shipments. Unlike a sales-rep app, the warehouse app has hardware constraints: rugged Android scanners, often no LTE in the warehouse, sometimes voice-pick integration.
3. Field service companion
Service techs see assigned jobs, customer history, parts on the truck, photos from past visits. Often offline-first — they’re in basements, attics, and rural job sites with no signal.
What MAUI brings to the table
- Single codebase across iOS, Android, Windows. The rep gets the iPhone app. The warehouse uses Android scanners. Operations uses Windows tablets. Same code.
- Native performance. Unlike React Native or Flutter (both fine choices for some teams), MAUI apps compile to native binaries with native UI controls. Lists scroll smoothly with thousands of items, which matters in catalog-heavy apps.
- The .NET ecosystem. If your backend is .NET (ASP.NET Core, EF Core, Azure Functions), sharing models, validation rules, and serialization between mobile and server is a real productivity win.
- Microsoft commitment. Xamarin is retired; MAUI is the successor with active investment. For a 5+ year app, that matters.
Where B2B mobile patterns differ from B2C
Authentication
B2C mobile uses social login or username/password. B2B mobile uses corporate identity — Azure AD / Entra ID, Okta, sometimes a custom IdP. The first-class mobile pattern is OIDC / OAuth2 with PKCE, with proper token refresh and a clean re-auth path when tokens expire mid-session. SAML still shows up in enterprise stacks, but on mobile it has to come in through a browser-based or broker flow (system browser, ASWebAuthenticationSession, AppAuth) — not a native SAML library. We use MSAL.NET for AAD-based apps; it’s mature and handles the edge cases.
Offline-first
B2C apps assume connectivity. B2B field apps don’t. The pattern that works:
- SQLite (via sqlite-net-pcl) as the local store
- Sync layer that records "intended actions" while offline (place order, mark job complete, capture signature) and replays them on reconnect
- Conflict resolution that’s explicit, not silent — if the same customer was edited online and offline, surface the conflict to the user
- Last-modified timestamps from the server so resync only pulls deltas
Push notifications
B2C push is for marketing. B2B push is operational — "your job assignment changed," "a quote came back from a customer," "low inventory alert on a SKU you watched." Keep them sparse and high-signal; users with three operational pushes a day stop reading them when one is "great deals on..."
Hardware integration
Barcode scanning, NFC, signature capture, photo capture with metadata, BLE for connecting to printers or label scales — all things that require platform-specific handlers. MAUI’s handler architecture is good for this; budget time for it.
The architecture we use
For most companion apps:
- MVVM with CommunityToolkit.Mvvm for the boilerplate (RelayCommand, ObservableProperty source generators)
- Shell for navigation if it’s a new app (URL-based, free flyout, search)
- Refit for typed REST clients to the ASP.NET Core backend
- Polly for retry/circuit-breaker on flaky connections
- Serilog writing to a local file + flushing to the server when online — when a rep says "my app crashed yesterday," the logs are there
- Crash reporting + diagnostics via Firebase Crashlytics, Sentry, Bugsnag, or Azure Monitor — pick one based on the rest of the customer’s observability stack. (Microsoft retired most of App Center after 2025-03-31; Analytics & Diagnostics support runs through 2027 only, so we don’t spec it for new projects.)
- Distribution via TestFlight / Google Play internal & closed tracks for staged rollouts, and MDM (Intune, Jamf, Workspace ONE) for enterprise / private-distribution builds. Avoid OTA “hot-fix” patterns — they violate Apple’s store policy.
What gets harder in MAUI vs. native
Honest things to plan for:
- Custom platform controls take more work than native — MAUI handlers are good but verbose. If your design has a lot of pixel-perfect requirements, allocate time.
- Deep native APIs (specific BLE quirks, particular camera behaviors) sometimes require platform-specific code. That’s normal in cross-platform; budget it.
- iOS distribution still requires an Apple Developer account, provisioning profiles, and the certificate dance even for enterprise B2B. Microsoft hasn’t made that easier.
The takeaway
B2B mobile companion apps are some of the most-used and least-flashy software in our portfolio. They live on devices for years, run alongside the storefront and the ERP, and they’re where rep productivity actually compounds. .NET MAUI is the right tool when your backend is .NET and your design tolerates native-feel UI; the patterns above are what we use to keep them maintainable past launch.
Sizing a companion-app project? Tell us about the device fleet and the workflow it pairs with — that’s how we estimate honestly instead of from a generic template.