C# / .NET MAUI Implementation
The actual build — shared codebase, platform handlers, offline-first where required, tested in CI. End-to-end accountability from one engineer.
<p>This is the build engagement. The architecture is decided (mine or yours); the deliverable is the running application on every target platform, the shared business-logic layer the platforms genuinely share, the platform handlers for the surfaces MAUI abstracts incompletely, the offline-first data layer where the buyer needs it, and the CI test coverage that proves it works before it ships.</p>
<p>The buyer for this page is a buyer who has the architecture decided (or is buying the sibling <a href="/services/mobile-app/design-architecture">Design & Architecture</a> engagement first) and needs the build executed by a single engineer with end-to-end accountability. The parent — <a href="/services/mobile-app">Mobile App Development</a> — sets the four-artifact perimeter; this page is the implementation specifically. Store submission is scoped on the sibling submission pages.</p>
<h2>Shared business logic</h2>
<p>Domain models, services, validators, and view models in the shared codebase. One implementation of every business rule — applied identically on iOS, Android, Windows, and macOS. The shared layer is unit-tested with the .NET test runner; tests run on the host (macOS for the iOS build, Windows for the rest) without launching the platform-specific surface, so the tests are fast and stable.</p>
<h2>Platform handlers</h2>
<p>Where the MAUI framework's defaults fall short, platform handlers fill the gap. Camera (per-platform capture quality, file format, EXIF handling). Geolocation (per-platform permission semantics, background-fetch policy). Biometrics (per-platform keychain or keystore integration, fallback to passcode). File system (per-platform sandbox, picker UI, MIME-type behavior). Background tasks (per-platform service contract, OS-driven scheduling). Push notifications (platform-specific provisioning, topic subscription, payload format). Each handler is scoped against the architecture document and implemented as a focused class with its own tests.</p>
<h2>Offline-first data layer</h2>
<p>For buyers whose field use case requires it. SQLite for local storage. Queued operations with idempotency keys. Synchronization with conflict resolution — last-writer-wins, three-way merge, or a domain-specific resolver depending on the entity. Observability into sync state in the UI rather than hidden in logs — the user sees what is pending, what is synced, what is conflicting. Background sync where the platform permits it; foreground sync everywhere with explicit user feedback.</p>
<h2>Cloud backend (where the engagement includes it)</h2>
<p>ASP.NET Core on .NET 10. Web API and minimal API endpoints. OIDC and JWT authentication, with Entra ID as the default identity provider for Microsoft-shop buyers and other OIDC providers (Auth0, Okta, custom) where the buyer's stack demands it. OpenAPI documents that match the running service. Optional gRPC where the wire format earns the complexity. Azure App Service or Container Apps deployment with infrastructure-as-code.</p>
<h2>What I ship</h2>
<ul>
<li><strong>The shared codebase.</strong> Domain models, services, view models, unit-tested.</li>
<li><strong>Platform handlers per surface.</strong> Camera, geolocation, biometrics, file system, background tasks, push notifications — each as a focused class with tests.</li>
<li><strong>Offline-first data layer (where required).</strong> Local SQLite, queued operations, conflict resolution, UI observability into sync state.</li>
<li><strong>Cloud backend (where included).</strong> ASP.NET Core Web API on .NET 10, OIDC auth, OpenAPI documents, Azure deployment.</li>
<li><strong>CI test coverage.</strong> Unit tests on the shared layer, integration tests on the cloud surface, platform-specific smoke tests in CI.</li>
<li><strong>Runbook.</strong> Build, sign, deploy, troubleshoot — for every platform.</li>
</ul>
<h2>Where it fits</h2>
<h3>Architecture decided, build needed</h3>
<p>The architecture document is in hand (mine or the buyer's existing team's). The build is the work. I take the document and ship the application, sprint by sprint, with a working build on every platform at the end of each sprint.</p>
<h3>Xamarin-to-MAUI migration</h3>
<p>The application is on Xamarin.Forms and Microsoft has wound down mainstream support. The migration is SDK conversion, handler and renderer rewrites, dependency-injection refactors, NuGet trim, and CI pipeline updates. A clean exit from a runtime that is no longer current, onto MAUI on .NET 10.</p>
<h3>Greenfield with end-to-end ownership</h3>
<p>The buyer wants one engineer carrying the build from first sprint to store submission. The shared codebase, the platform handlers, the cloud backend, and the submission to Apple, Google, and Microsoft are all the same hands. No handoff to a "store ops" vendor; no separate backend team that does not see the MAUI client.</p>
<h2>How I work</h2>
<p>Implementation runs in two-week sprints. Working build on every platform at the end of each sprint. Pest is not the test runner here — the .NET test runner is. CI runs the test suite on every push and blocks merges on red. Pint is not the formatter; the .NET formatter is. The principal carrying the work is described <a href="/about">on the about page</a>.</p>
<h2>Engagement model</h2>
<p>Implementation runs eight to twenty weeks depending on scope, platform count, offline-first complexity, and whether the cloud backend is in scope. Store submission runs in parallel with the final sprint via the sibling <a href="/services/mobile-app/apple-app-store">Apple App Store</a> and <a href="/services/mobile-app/google-play-microsoft-store">Google Play + Microsoft Store</a> submission pages. Handover includes the running application on every platform, the test suite, the IaC, the runbook, and a 30-day post-launch support window. To scope a build, <a href="/contact">get in touch</a>.</p>