Cross-Platform App Design & Architecture
The architecture, UX, and platform-strategy decisions made before the first line of MAUI code — so the build does not get refactored in month three.
<p>This is the architecture engagement. The deliverable is a written architecture document — UX across the form factors the app will ship to, MVVM patterns and the container choices, navigation strategy, theming, accessibility, internationalization, platform-handler surface — that the implementation team (whether me, the buyer's team, or both) builds against. The work is the decisions that prevent the build from getting refactored in month three.</p>
<p>The buyer for this page is a product owner or engineering leader who has the requirements and wants the architectural decisions made by an engineer who has shipped this stack before, not learned on their dime. The parent — <a href="/services/mobile-app">Mobile App Development</a> — sets the four-artifact perimeter; this page is the architecture-first shape of the work.</p>
<h2>UX across form factors</h2>
<p>Phone, tablet, and desktop where the app is shipping to Windows or macOS. The UX decisions — navigation shell vs traditional navigation, master-detail vs stack, primary action placement, responsive breakpoints — happen at the design phase, not at the platform-specific bug-fix phase. The design system is documented in a way the platform handlers can implement consistently across iOS, Android, Windows, and macOS.</p>
<h2>MVVM architecture decisions</h2>
<p>Dependency injection container (the .NET 10 default, or a third-party choice if the buyer's existing pattern requires it). Messaging between view models (the Community Toolkit messenger, or a custom approach). State management — how the application stores ephemeral state, persistent state, and offline state. Persistence layer — SQLite, Entity Framework Core, or a hosted database depending on the deployment target. The Community Toolkit patterns adopted where they earn the complexity, skipped where they do not.</p>
<h2>Theming, accessibility, internationalization</h2>
<p>Color palettes for light and dark; theming that survives a system-theme change at runtime. Accessibility (VoiceOver, TalkBack, Narrator) as a build requirement — text scaling, contrast, focus order, semantic labels. Internationalization scoped to the target locales; RTL where the locales demand it. These decisions go in the architecture document, not in a post-launch refactor.</p>
<h2>Platform-handler surface</h2>
<p>Where does the framework abstract well, and where does it abstract incompletely? Camera, geolocation, file system, biometrics, background tasks, push notifications, deep linking — each gets a documented platform-handler approach before the build starts, so the first month of implementation is not a survey of where MAUI defaults fall short.</p>
<h2>What I ship</h2>
<ul>
<li><strong>Architecture document.</strong> UX decisions, MVVM patterns, DI container, messaging, state, persistence, theming, accessibility, i18n, platform handlers.</li>
<li><strong>Design-system definition.</strong> Documented for the platform handlers to implement consistently.</li>
<li><strong>Sprint plan.</strong> Phased implementation with decision points before each sprint.</li>
<li><strong>Risk register.</strong> Where MAUI is the right answer, where it might not be, where a platform-specific spike is needed before commitment.</li>
<li><strong>Hand-off package.</strong> The document, the design system, the sprint plan — ready for the implementation team.</li>
</ul>
<h2>Where it fits</h2>
<h3>Pre-build architecture</h3>
<p>The buyer has the requirements. The decisions on platform handlers, MVVM patterns, and design system have not been made. I make them, document them, and hand the architecture to the implementation team — either my own engagement that continues into the sibling <a href="/services/mobile-app/maui-implementation">.NET MAUI Implementation</a> page, or the buyer's internal team.</p>
<h3>Mid-build course correction</h3>
<p>The build is two months in. Decisions made in week one are showing strain. The buyer wants a written architecture review and a remediation plan — what to refactor, what to leave, where to draw the line on retrofitting versus rewriting.</p>
<h3>Architecture review before implementation handover</h3>
<p>An offshore or contracted team is about to start the build. The buyer wants the architecture validated by an engineer who has shipped MAUI before — not learned what platform handlers are after the first sprint demo.</p>
<h2>How I work</h2>
<p>Discovery and architecture run two to four weeks depending on scope. The output is the document, the design system, the sprint plan, and the risk register. I do not commit to architecture decisions inside a one-day workshop; the decisions need to be tested against the actual requirements and the actual platform constraints. The principal carrying the work is described <a href="/about">on the about page</a>.</p>
<h2>Engagement model</h2>
<p>Two- to four-week engagement. Deliverables are the written architecture, the design-system definition, the sprint plan, and the risk register. Follow-on implementation is scoped on the sibling <a href="/services/mobile-app/maui-implementation">.NET MAUI Implementation</a> page. To scope an architecture engagement, <a href="/contact">get in touch</a>.</p>