Independent Engineering · Mobile
When a progressive web app isn't enough — because work happens offline, because hardware has to come along (camera, barcode, Bluetooth, NFC), because it should be findable in the App Store. We build iOS and Android apps with .NET MAUI for Microsoft-adjacent stacks, React Native for broad cross-platform projects, or native Swift/Kotlin when the task demands it.
Decision support
A native app is more expensive and complex to operate than a web application. Four scenarios where the effort is worth it — and three where you're better off staying with a PWA.
Service technicians in the engine room, in the basement, or at the mast. No Wi-Fi, fluctuating cellular signal. The job still has to be completed, documented, and synced later. A native app with local SQLite and a sync engine is without alternative here.
Warehouse inventory with barcode scanner. Asset tagging via NFC. Connection to Bluetooth sensors in industrial or healthcare settings. Browser APIs cover part of this — but not stably enough for daily use with hundreds of operations per shift.
End customers find you via Apple App Store or Google Play. A PWA reachable only via a URL doesn't show up there. When the App Store is part of the sales channel, you need a real app with an App Store listing.
When the app is used several times a day for 30+ minutes each — logistics tours, nursing care, service field work — every second of latency and every bit of battery counts. Native apps are significantly more performant and energy-efficient than web-based alternatives.
Internal tool used occasionally on a smartphone, no offline need, no hardware integration. Here you build a progressive web app with Next.js: 60% of the functionality, 25% of the cost, no App Store approval cycle.
Data-driven internal mobile applications with 5–50 users who are already working in a Microsoft tenant. Here, Microsoft Power Apps is typically productive in 4–8 weeks — without anyone having to endure an App Store approval process.
Tech stack
A stack decision is long-term — mobile apps live three to five years, often longer. We choose per project, deliberately and with justification, instead of forcing a house preference.
Microsoft's cross-platform framework, successor to Xamarin Forms. One C# codebase covers iOS, Android, macOS, and Windows. Makes sense when you already use Dynamics 365, Power Platform, or a .NET backend stack — the auth libraries (MSAL), Dataverse connectivity, and Microsoft identity story are most mature here. Our default for B2B field apps with Microsoft integration.
JavaScript/TypeScript-based framework from Meta, with the largest ecosystem of open-source components. Makes sense when the web team thinks in TypeScript and code sharing between web and mobile is useful (e.g. validation logic, API clients). We typically use it with Expo, which simplifies build tooling and update pipelines.
When AR features (ARKit / ARCore), CoreML inference on the device, professional audio/video processing, or pixel-perfect UI animations are required, there's no alternative to native development. SwiftUI for iOS, Jetpack Compose for Android. Here we deliver single-platform — higher effort, but maximum platform depth.
Offline-capable apps need a local data store, typically SQLite — directly or via Realm or WatermelonDB. We choose sync strategies (last-write-wins, operational transforms, CRDTs) based on conflict tolerance. For Microsoft Dynamics 365 / Dataverse-backed apps we use the Microsoft Field Service sync mechanism or build a custom one if necessary.
Authentication runs via OAuth 2.0 with PKCE; tokens are stored in the platform's own secure storage (Keychain on iOS, Keystore on Android). For Microsoft integration we use MSAL (Microsoft Authentication Library), which brings Conditional Access, MFA, and single sign-on out of the box.
Three project shapes
Which form fits depends on where you are and whether the app should be a standalone product or part of a larger platform.
You know an app is needed, but not whether native or cross-platform, with custom backend or via Dataverse, whether a store approval is realistic. We validate technical assumptions, clarify platform strategy, check Apple/Google accounts, and deliver a decision template + roadmap.
From spike to a published app. We build the core workflows in a .NET MAUI or React Native codebase, set up build pipelines (TestFlight, Play Console internal track), and run the store approval. First real users can test after 3–4 months; public release is realistic after 5–8 months depending on complexity.
You already have an app in the store but need ongoing development — new features, OS updates (yearly), third-party SDK migrations. 1–2 mobile engineers work with you on your team, in your pipeline, with your reviews.
Microsoft integration
If you're already in the Microsoft stack, that significantly simplifies a mobile app strategy. Four concrete anchor points where we integrate deeply:
Dynamics 365 Field Service — as backend. Service orders, dispatching, asset data, service reports: all present in the Field Service data model. We build the mobile app either on the Microsoft Field Service Mobile SDK or directly against the Dataverse Web API, depending on how much customization is needed.
Dynamics 365 Sales — as backend. Field sales apps with lead capture, account overview, appointment preparation. Offline-capable mirroring of accounts, contacts, and opportunities.
Microsoft Entra ID — as identity provider. Single sign-on into the app via MSAL, Conditional Access (e.g. "allowed only from Germany"), MFA via Authenticator. No separate user login, no separate password management.
Microsoft Intune — as MDM and distribution channel. For internal apps, we distribute via Intune Company Portal instead of App Store / Play Store. Plus compliance policies (device encryption, PIN enforcement, remote wipe). Useful when the app shouldn't be public or when company-wide device control is needed.
Sovereignty in mobile
Backend hosting in the EU — fully controllable. Custom backend at Hetzner, STACKIT, IONOS, or OTC. Database, object storage, identity provider — all under EU law and without Cloud Act exposure. With Microsoft backend (Dataverse), the Microsoft EU Data Boundary commitment applies; it limits but doesn't eliminate Schrems II risks.
App Stores — not sovereign, but unavoidable. Apple App Store and Google Play are US infrastructure. For publicly distributed apps, that's the reality. For purely internal apps, alternatives exist: Intune Company Portal, Apple Business Manager with a private distribution program, sideloading on Android.
EU-compliant telemetry. Crash reporting via Sentry self-hosted (or Sentry EU tenant), analytics via Plausible or Matomo (instead of Firebase Analytics or Google Analytics 4). Push notifications via APNs / FCM can't be avoided, but we reduce the payload to what's necessary and encrypt sensitive content portions.
Data model and local storage. Only auth tokens reside in the device's secure storage (Keychain / Keystore). Business data in a SQLite database, encrypted with the platform's own disk protection. For very sensitive data, additionally at app level with AES-256 (e.g. SQLCipher).
Further
The backend for your mobile app — TypeScript/NestJS/PostgreSQL, EU-hosted, in your code ownership. Or the web variant as a progressive web app, if a native app isn't necessary.
For internal mobile apps with 5–50 users, often the faster answer. Canvas apps for form-driven use cases, model-driven for Dataverse-centric applications.
When the mobile app is the tool for service technicians and the standard functional scope is sufficient — Microsoft's Field Service Mobile SDK is the most direct path.
Before you open an App Store account: platform strategy, build-vs-buy, backend choice, distribution model. 45 minutes at the whiteboard save 4 weeks of concept phase.
FAQ
When the app must work offline, needs hardware access (camera, Bluetooth, barcode scanner, NFC, background sync), or must be found in the App Store/Play Store. Also for very long sessions where web performance hits its limits. In all other cases, we first check whether a PWA is sufficient — it's significantly cheaper to build and run.
Cross-platform (.NET MAUI or React Native) is the right answer in 80% of B2B cases: one codebase, two platforms, significantly smaller team. Native (Swift/SwiftUI for iOS, Kotlin/Jetpack Compose for Android) makes sense for AR/VR, on-device ML inference, real-time audio, or UI-intensive consumer apps. For mid-market apps with Microsoft integration, .NET MAUI is usually the most pragmatic path.
Via the Dataverse Web API with OAuth 2.0 tokens from Microsoft Entra ID. For field-service scenarios there's the Field Service Mobile SDK; we build on it when the standard functional scope is sufficient. For custom workflows we access Dataverse directly, with configurable offline cache and sync logic.
Three paths: (1) Public App Store / Play Store for customer-facing apps. (2) Enterprise distribution via Microsoft Intune (Company Portal) — for internal apps that shouldn't be public. (3) Apple Business Manager / Apple Developer Enterprise Program for very large iOS fleets. We set up build pipelines so every push to main automatically builds a TestFlight or internal-track version.
Three realistic paths: (1) Microsoft stack — Dataverse + Power Platform APIs + Azure Functions, if you're already in the Microsoft ecosystem. (2) Custom backend in our stack — TypeScript/NestJS on PostgreSQL, hosted at Hetzner or STACKIT (EU sovereignty). (3) Hybrid — Dynamics data via Dataverse API, supplemented by a custom backend for features D365 doesn't cover. We help with the decision in the architecture conversation.
The backend can be fully EU-sovereign (Hetzner / STACKIT / IONOS / OTC). App Stores themselves are US infrastructure (Apple, Google) — you can't get around that for publicly distributed apps. Telemetry (crash reporting, analytics) we configure EU-compliant: Sentry self-hosted or Plausible instead of Firebase Crashlytics. Push notifications run via APNs/FCM — the question is how much payload you transmit encrypted.
Discovery spike (2–4 weeks): clarifies use cases, platforms, backend strategy, App Store accounts — fixed price. MVP of a simple iOS+Android app via .NET MAUI: typically 3–5 months. MVP of an app with complex offline sync and hardware integration: 5–8 months. Embedded team (1–2 mobile engineers, monthly): ongoing evolution with the customer's own product team. Concrete numbers we give together after discovery.
Yes. If you already have a REST/GraphQL API or Dynamics 365 / Dataverse, we take on the mobile part and connect. Prerequisite: the API is documented (OpenAPI / Postman collection) and auth is clear (OAuth 2.0, OIDC, JWT). For undocumented backends, the project starts with an API audit.
30 min · free · no obligation
30 minutes in which we walk through your specific use case — platforms, backend, distribution model, App Store reality. No prep pressure — bring what you have.
Accompanying services
Engineering projects rarely stand alone — license logic, architecture clarification, quality gates, knowledge transfer, and follow-on operations usually run in parallel. Below are the most common accompanying services we add via discovery spikes, fixed-price sprints, or application-care contracts.
Before · Architecture
Before implementation: tenant structure, data model, security concept, integration mapping. The result is an architecture document any engineering team can continue working with — even one other than us.
Read more →
Before · CSP
Which license bundles for which users, which add-on SKUs are necessary, where you're over- or under-licensed. Sourced as a Microsoft Licensing Partner — with the option to use CSP purely for control without margin maximization.
Read more →
During · Quality gate
Independent second opinion during an active implementation project — whether we run it or another partner does. CMMI-based quality gates, risk reviews, fixed price per gate.
During · Adoption
Not the classic 2-day workshop forgotten after a week — but a dynamic learning program over 4–6 weeks with initial training, application phases, and follow-up sessions. Training matrix for roles and topics.
Read more →
After · Operations
After go-live: a plannable application-care contract with a monthly flat rate, SLA-based. Includes releases, hotfixes, extensions, tenant hardening — and continuous accompaniment instead of mere ticket response.
Read more →
After · Knowledge
When the original developers are gone, the previous partner is no longer reachable, or the documentation is stale — reverse engineering of the existing solution with a documented result: code map, data model, customization inventory.
Read more →
