.NET MAUI Development & Xamarin Migration

Microsoft ended support for all Xamarin SDKs on 1 May 2024. The apps don't stop working on that date - but Xamarin no longer gets updates for new Android and iOS releases, and Google Play and the App Store regularly raise the SDK versions they accept. An unmigrated Xamarin app eventually can't ship updates at all, including security fixes.

.NET MAUI is Xamarin's official successor. It keeps C#, XAML and most of your shared code, which makes it the lowest-risk path for an existing Xamarin app.

If your team and back end are .NET, MAUI lets you share models, validation and API clients across server and app and keep one language. For a brand-new consumer app with heavily custom UI and no .NET investment, Flutter or React Native can be the better fit - we build all three and will recommend honestly.

For existing Xamarin apps the answer is almost always MAUI: it reuses the most code and the most of your team's knowledge.

A .NET MAUI Blazor Hybrid app hosts Razor components in a native BlazorWebView. The components run directly in the .NET process on the device - not in WebAssembly and not on a server - so they have full access to device APIs through ordinary C# services, and they work offline.

It suits teams that already have a Blazor or ASP.NET Core web app: the same component library can power the website, a desktop app for Windows and macOS, and the mobile app. The trade-off is that the UI renders as HTML and CSS rather than native controls, so it looks like your web app rather than a stock iOS or Android app. For internal tools, field apps and line-of-business software that is usually exactly what the client wants.

One codebase does not mean zero platform code. Push notifications, background work, biometrics, file pickers, Bluetooth and deep links all behave differently on iOS and Android. MAUI handles this cleanly with the Platforms folders, partial classes and conditional compilation, and handler mappers let you change how a single control renders on one platform without a full custom renderer.

Our rule is to keep platform code thin and behind interfaces, so the shared layer stays testable and a later OS change touches one file instead of every screen. Where a native SDK has no .NET binding, we create one or call it through a small platform-specific wrapper.

MAUI development runs in Visual Studio on Windows or VS Code with the .NET MAUI extension, and iOS builds always need a Mac with Xcode - either a paired Mac on the network or a macOS build agent in the cloud. We set up CI pipelines in GitHub Actions or Azure DevOps that build Android and iOS on every pull request, run unit and UI tests, sign the packages and push builds to TestFlight and the Google Play internal testing track.

AI tools speed up this part too: your developer uses them to draft pipeline YAML, signing scripts and UI test scaffolding, then reviews and runs each one against real devices before it reaches the stores.