Mobile
Xamarin
Xamarin is end of life. We keep existing Xamarin apps running and move them to .NET MAUI on a managed timeline — no drama, no rewrite-for-the-sake-of-it.
Overview
Xamarin is Microsoft’s original cross-platform mobile framework: build native iOS and Android apps in C# and .NET, sharing your business logic — and, with Xamarin.Forms, much of your UI — across both platforms from a single codebase. It compiles to native code and gives you access to the underlying platform APIs, so a well-built Xamarin app looks and performs like a native one rather than a wrapped web view. For years it was the natural choice for .NET and C# shops, and for enterprises that already ran on Microsoft tooling and wanted to reuse those skills on mobile.
There is one fact that has to sit at the top of any honest page about Xamarin: it has reached end of support. Microsoft ended Xamarin support in May 2024, and its successor is .NET MAUI (Multi-platform App UI) — effectively Xamarin.Forms rebuilt on modern .NET. That single fact changes what this technology is for. No one should start a new app in Xamarin today. The real work is different: keeping the Xamarin apps that businesses already depend on running safely, and migrating them onto .NET MAUI or another modern framework before the end-of-life status turns into a security or store-compliance problem.
That is exactly the work we do. We maintain and stabilise existing Xamarin apps, and we plan and execute migrations to .NET MAUI that reuse the shared C#/.NET codebase you already paid for — the business logic, the view models, the service layer — rather than throwing it away and rebuilding from a blank editor. We are blunt about the trade-offs at each step, and we will tell you when a straight migration is the wrong call and a rewrite in a different framework serves you better. If you are here for a greenfield app, this is not the page for you, and we will say so.
Best for — Businesses running an existing Xamarin app that needs ongoing maintenance, or a planned, low-risk migration to .NET MAUI that keeps the C#/.NET codebase intact — not new projects.
Why teams choose Xamarin
Your existing app keeps working
End of support does not mean your app stops overnight — but it does mean the clock is running on OS and store compatibility. We keep the current app stable and compliant while the migration is planned, so you are never forced into a rushed rewrite by a rejected store submission.
You keep the codebase you paid for
Migrating Xamarin.Forms to .NET MAUI reuses the shared C#/.NET code — business logic, view models, service and data layers — that carries most of your app’s value. That is the difference between a migration measured in weeks and a rewrite measured in months.
A supported platform, again
Moving to .NET MAUI puts you back on a framework Microsoft actively maintains, with security patches, current toolchain support and new OS compatibility — removing the standing risk that comes with running production software on an end-of-life stack.
Why businesses choose Xamarin
- You have a real, working Xamarin app in production and need it kept stable and compliant while you decide what comes next.
- You want to move to .NET MAUI on a planned timeline that reuses your existing C#/.NET code, rather than a panicked rewrite triggered by a store rejection.
- You value an honest assessment of whether to migrate or rebuild — including being told when a rewrite in a different framework is the better use of money.
- You want senior engineers who understand both the old framework and its successor, so nothing is lost in translation between Xamarin and MAUI.
What we build with Xamarin
The capabilities this technology is genuinely strong at — and what we most often build with it.
Xamarin.Forms and Xamarin.Native
Xamarin comes in two shapes: Xamarin.Forms, which shares a single UI definition across iOS and Android, and Xamarin.Native (Xamarin.iOS and Xamarin.Android), which shares logic but builds each platform’s UI separately. Which one an app uses largely determines how its migration to MAUI plays out, so identifying it is our first move.
Shared C#/.NET business logic
The core value of a Xamarin app is the C# it shares across platforms — models, view models, services, validation and data access. This is the code we prioritise preserving, because it is portable to .NET MAUI and carries most of the behaviour your users depend on.
MVVM and data binding
Most serious Xamarin apps are built on MVVM with XAML and data binding. That pattern survives the move to MAUI almost intact, which is precisely why a disciplined MVVM Xamarin.Forms app is far cheaper to migrate than one with logic tangled into the UI.
Native API access via bindings
Xamarin exposes platform capabilities — camera, geolocation, secure storage, Bluetooth, native SDKs — through bindings and dependency services. We audit these carefully during migration, because native integrations are where the equivalent MAUI or third-party APIs most often differ.
The .NET MAUI upgrade path
MAUI is the sanctioned successor, and the .NET Upgrade Assistant automates part of the project conversion. It is a starting point, not a finish line: namespaces, control names, custom renderers and platform effects still need hands-on work, which is the part we do properly rather than pretend is push-button.
Custom renderers and platform effects
Xamarin.Forms customises native controls through custom renderers; MAUI replaces these with a handler architecture. Translating renderers to handlers is one of the more involved parts of a migration, and getting it right is what keeps the migrated UI looking and behaving as it did.
Use cases
Ongoing maintenance of a live Xamarin app
Keeping a production app healthy on an end-of-life framework: fixing bugs, updating dependencies where still possible, and meeting new App Store and Play Store submission rules so releases keep going out.
Migration from Xamarin.Forms to .NET MAUI
The core engagement — moving an existing Xamarin.Forms app onto .NET MAUI, porting the shared C#, converting renderers to handlers, and re-validating native integrations, on a staged, low-risk plan.
Stabilise-then-migrate for a stalled project
Taking on an app that has drifted — abandoned by its original team, failing to build, or blocked from store updates — stabilising it first, then planning the move to a supported platform once it is safe.
Migrate-or-rebuild assessment
A senior review of an existing Xamarin app that answers one question honestly: is this worth migrating to MAUI, or is a rewrite in another framework the better spend? You get a costed recommendation, not a sales pitch for the option that suits us.
When Xamarin is the right choice
- Right when you have an existing Xamarin app in production that needs maintenance — bug fixes, dependency updates, keeping it working as iOS and Android release new OS versions and tighten App Store and Play Store requirements.
- Right when you need a managed migration from Xamarin to .NET MAUI, and want to preserve the shared C#/.NET codebase — business logic, view models and services — rather than fund a full rewrite.
- Right when a Xamarin app is on Xamarin.Forms already: that is the codebase MAUI was designed to receive, so the migration path is well understood even where it is not effortless.
- Wrong for any new app. Xamarin is end of life — starting greenfield work in it means building on a framework Microsoft no longer supports. New apps should start in .NET MAUI, React Native, Flutter, or fully native, and we will help you choose.
- Wrong when the existing app is small, barely used, or cheaper to rebuild than to migrate. Migration is worth it when there is real, working logic to preserve; when there is not, we will tell you a fresh build is the honest answer.
Xamarin: pros and cons
Strengths
- Native iOS and Android from a single C#/.NET codebase, with genuine access to platform APIs and native performance — not a web-view wrapper.
- A strong fit for teams already invested in .NET and C#: existing skills, tooling and back-end code carry straight across to mobile.
- Its shared codebase is the very thing that makes the migration to .NET MAUI tractable — much of the logic moves largely intact.
- A mature, well-documented framework with years of production use behind it, so the problems you hit on an existing app are known problems.
Trade-offs
- It is end of life. Microsoft ended Xamarin support in May 2024, so there are no more platform updates or security patches — leaving an app un-migrated is a growing risk, not a stable state.
- OS and store compatibility degrades over time: new iOS and Android versions and tightening App Store and Play Store rules will eventually break or block an un-maintained Xamarin app.
- The ecosystem is shrinking — libraries, plugins and community support are winding down as the world moves to .NET MAUI and other modern frameworks.
- It is now a legacy concern, not a forward choice. Any Xamarin engagement is fundamentally about maintenance or exit, and building anything new on it only deepens the eventual migration cost.
Architecture
The architecture of a Xamarin app decides how hard its migration will be, so that is where we start. A clean app separates its shared C# core — models, view models, services, data access — from the platform-specific UI and native bindings. Where that separation holds, the core moves to .NET MAUI largely intact and the work concentrates on the UI layer. Where business logic has leaked into pages and code-behind, migration is slower and riskier, and we are honest about that up front rather than discovering it halfway through.
For a migration to MAUI, the shape of the target matters as much as the source. MAUI keeps the MVVM and XAML model Xamarin.Forms developers know, but replaces custom renderers with handlers and reorganises the project into a single multi-targeted structure rather than separate platform projects. We map the existing renderers, effects, dependency services and platform code to their MAUI equivalents before writing anything, so the migration follows a plan rather than a series of surprises. When a Xamarin.Native app is involved, we assess whether it belongs in MAUI at all, or whether its platform-specific UI makes a different path more sensible.
Performance
Xamarin compiles to native code, so a well-built app performs close to a fully native one; the performance problems we see in the field are rarely about the framework itself. They are ageing dependencies, memory leaks from mishandled event subscriptions and bindings, slow startup from doing too much on the main thread, and layout inefficiency in complex Xamarin.Forms pages. On a live app, we profile and fix these directly rather than treating end of life as a reason to stop caring about how it runs.
Migrating to .NET MAUI is also a performance opportunity, not just a compliance exercise. MAUI’s handler architecture is lighter than Xamarin.Forms’ renderer model, and moving onto current .NET brings startup and runtime improvements for free. We measure before and after — startup time, memory, scroll and interaction smoothness — so the migration can be judged on evidence, and so any regression introduced in the port is caught and fixed rather than shipped.
Security
Security is the sharpest reason not to leave a Xamarin app un-migrated. End of support means no more security patches to the framework or its runtime, so any vulnerability discovered from May 2024 onward stays unpatched at the platform level. For an app handling logins, payments or personal data, that is a standing risk that only grows, and it is the argument we make plainly to businesses weighing whether a migration is worth funding.
While an app remains on Xamarin, we reduce exposure where we still can: updating third-party dependencies that do release fixes, hardening data handling and secure storage, enforcing correct certificate and transport security, and keeping platform-level protections current. But we are clear that this is mitigation, not a cure — the durable fix is getting onto a supported framework. Migration to .NET MAUI restores a patched, maintained runtime, and we treat that as the real security deliverable rather than a side effect.
Scalability
For a mobile app, scalability is less about server load and more about whether the codebase can keep absorbing change — new OS versions, new store rules, new features — without becoming unmaintainable. On Xamarin, that runway is now finite by definition: the framework will not gain support for future platform capabilities, so every year on it is a year of accumulating constraint rather than growing headroom.
A migration to .NET MAUI restores that headroom. It puts the app back on a platform that tracks new iOS and Android releases, receives tooling and language updates, and shares a code model with the wider modern .NET ecosystem — so the same team that runs your back end can extend the mobile app. We plan migrations so the result is not just a like-for-like port but a codebase your team can keep building on for years, which is the only version of scalability that means anything for an app in this position.
Xamarin integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work with Xamarin
We start every Xamarin engagement with an honest audit: which flavour the app uses, how cleanly the shared C# is separated from the UI, which native integrations and custom renderers exist, and what state the dependencies are in. That audit produces a costed recommendation — maintain, migrate to .NET MAUI, or rebuild — and we will argue against migration when a rewrite is genuinely the better spend. We would rather lose the migration than sell you one you do not need.
When migration is the right call, we do it in staged, verifiable slices rather than one big-bang conversion. The shared logic moves first and is tested in isolation; then the UI is ported screen by screen, renderers converted to handlers, native integrations re-validated on real devices, and each slice checked against the behaviour of the app it replaces. The engineers doing the migration are the ones who understand both frameworks and who will support the result — we operate what we build, so we plan for the maintenance reality after the migration, not just the moment it compiles.
The service behind it
Delivered throughMobile App DevelopmentWhat we build with Xamarin
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use Xamarin in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Mobile
Why teams choose us for Xamarin
We know both sides of the migration
Our engineers understand Xamarin and its Xamarin.Forms internals and .NET MAUI’s handler model — so custom renderers, dependency services and native bindings are translated correctly, not approximated and hoped for.
Honest about migrate versus rebuild
The audit gives you a straight answer, including when a rewrite in another framework beats a MAUI migration. We would rather tell you that than bill you for the wrong route.
We operate what we build
The people who migrate your app support it afterwards, so we plan for the maintenance reality on modern .NET — not just a build that passes and a codebase your own team then struggles to keep alive.
Senior engineers only
Legacy migration is where inexperience is most expensive — the failure modes are subtle and surface late. There are no juniors learning on your production app on our watch.
Typical timeline
- 01
Audit and recommendation
One to two weeks assessing the app — flavour, code separation, native integrations, dependency health — and delivering a costed decision to maintain, migrate or rebuild.
- 02
Stabilise the existing app
Where needed, getting the current app building, releasing and store-compliant first, so there is no compatibility cliff while the migration runs.
- 03
Migrate in slices
Shared C# ported and tested first, then the UI screen by screen with renderers converted to handlers and native integrations re-validated on real devices.
- 04
Verify and hand over
Before-and-after performance checks, testing on the load-bearing flows, store submission of the MAUI build, and documentation so your team can own it.
How pricing works
- A fixed-price migration audit — the app assessed, the path chosen, and a costed migrate-or-rebuild recommendation delivered as a document you own, whether or not you go on to hire us for the work.
- Fixed-scope migration to .NET MAUI for a well-understood app, quoted once the audit has established the shape and size of the codebase.
- Monthly senior engagement for ongoing Xamarin maintenance and a phased migration, where you want continuity and a steady exit from end-of-life rather than a single deliverable.
Hire Xamarin engineers
Need Xamarin capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire Xamarin engineersCommon questions
Is Xamarin still supported?
No. Microsoft ended support for Xamarin in May 2024, so it receives no further platform updates or security patches. Existing apps keep running for now, but the lack of updates means OS and app-store compatibility will degrade over time, and any new framework-level vulnerability stays unpatched. The recommended path is to migrate to .NET MAUI, Xamarin’s official successor.
Should we build a new app in Xamarin?
No — and we will say so plainly. Xamarin is end of life, so starting a new app in it means building on an unsupported framework and inheriting a migration you will have to fund later. New cross-platform apps should start in .NET MAUI if you want to stay in the .NET world, or in React Native, Flutter, or fully native depending on your needs. We will help you choose the right one.
What is the difference between Xamarin and .NET MAUI?
.NET MAUI is effectively Xamarin.Forms rebuilt on modern .NET — the same MVVM and XAML model, but with a lighter handler architecture in place of custom renderers, a single multi-targeted project instead of separate platform projects, and, crucially, active Microsoft support. It is the sanctioned upgrade path for Xamarin, which is why most Xamarin apps migrate to MAUI rather than being rewritten from scratch.
How much of our Xamarin codebase can we reuse when migrating to MAUI?
It depends on how the app was built, but the shared C# — business logic, view models, services and data access — usually moves across with limited change, and that is where most of an app’s value sits. The UI layer needs more work: custom renderers become handlers, some control names and namespaces change, and native integrations must be re-validated. A clean, MVVM-based Xamarin.Forms app migrates far more cheaply than one with logic tangled into its pages.
Should we migrate to MAUI or rebuild the app from scratch?
That is exactly what our audit answers. Migration wins when there is substantial, working logic worth preserving and the app is reasonably well structured. A rebuild can win when the app is small, the codebase is a mess, or your requirements have changed enough that a fresh start in a different framework is cheaper than untangling the old one. We give you a costed recommendation either way, and we are willing to advise against migration when that is the honest answer.
Building on Xamarin?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.