Why a Xamarin to .NET MAUI migration is due
Xamarin no longer receives updates. .NET MAUI keeps the same C# base, with one project, handlers instead of renderers, and current .NET.
Microsoft ended support for Xamarin on 1 May 2024. New iOS and Android SDKs, store rules and security fixes no longer land on Xamarin.Forms or Xamarin.Native.
.NET MAUI (Multi-platform App UI) is the intended successor. One codebase covers iOS, Android and, when needed, Windows and macOS. Teams that already use C#, ASP.NET Core or Azure stay inside that stack.
Source: Microsoft Xamarin support policy, end of support 1 May 2024. The legacy platform is described on our Xamarin page. The migration itself is a separate service, delivered from Leer, Germany.
What changes between Xamarin.Forms and .NET MAUI
A namespace swap is not the project. The architecture moves from several platform projects to a MAUI single project. Discovery always covers these points:
- Custom renderers become handlers. Every custom control needs an acceptance test.
- Xamarin.Essentials moves into the MAUI APIs. Camera, files and location calls are updated.
- NuGet packages without a MAUI target are replaced or wrapped behind a narrow interface.
- Separate iOS and Android projects fold into platform folders of the single project.
- The target framework is current .NET, not the old Xamarin Mono profile.
Shared cross-platform logic is the reason to stay on the Microsoft stack. iOS and Android UI exceptions are handled in place, not by shipping a second app.
How the migration runs
1. Inventory of the Xamarin solution
We read projects, target frameworks, NuGet status and custom controls. Store accounts, signing and business-critical flows sit on the same list. The output is a cut: keep, adapt or replace.
2. Target shape in .NET MAUI
We fix the .NET version, the single project and the handler strategy. Business logic moves into libraries that the old and new apps can share for a while. That keeps a rollback path open.
3. UI and device access, module by module
Screens and device features move in slices: login, offline data, push, Bluetooth. Each slice has acceptance criteria taken from the current app. Gaps show up in the test build, not in the public store.
4. Store release and hypercare
TestFlight and Play test tracks run beside the Xamarin version. We replace the store package only after business sign-off. The first weeks after release are part of the service, including crash review.
.NET MAUI, Flutter or a rewrite
.NET MAUI is the economical path when a lot of C# is already sound. Moving to Flutter or React Native rebuilds the UI and often the client logic. That pays off when the design system is new or no .NET team will maintain the app.
New mobile products without a Xamarin estate are planned in app development. Desktop targets on the same stack belong with desktop software. If more than the app is legacy, legacy modernization stays the wider frame.
Example: a smart-home app moved from Xamarin to .NET MAUI
We continued the ESYLUX smart-home app and migrated it from Xamarin to .NET MAUI. Lighting, automation, projects and devices stay operable. Bluetooth and Wi-Fi run on the new base without throwing away the existing user flow.
The write-up is the ESYLUX smart-home app case study. Similar device apps with .NET on the backend follow the same cut: libraries first, UI next, store last.
Effort and the next step
Investment is set as fixed-price milestones after discovery. A full rewrite is positioned by the app development cost calculator. A migration stays leaner while C# logic, models and API clients remain. Groenewold IT Solutions experience: lean Forms apps often take weeks; apps with custom UI and device protocols take several months.
The first call needs repository access or an architecture sketch, the store names and the list of critical flows. From that we cut what continues in .NET MAUI and what must be rebuilt.
