TL;DR - Microsoft ended Xamarin support on 1 May 2024, and the app stores have since moved past what Xamarin can build. If you're hiring a Xamarin developer in 2026, you're really hiring someone to make one of three calls about an existing app: keep it alive briefly, migrate it to .NET MAUI, or rebuild it. Hire for that decision, not for Xamarin skills alone.
If you searched "hire Xamarin developers" this year, you probably aren't starting a new project in Xamarin. Nobody should be. You have an app that already works, earns money or runs a business process, and it has started to break in ways your team can't fix quickly: an App Store upload rejected, a Play Console warning about target API levels, a NuGet package that no longer installs, or a developer who left and took the build setup with them.
That changes what you should look for. A developer who knows Xamarin.Forms well is useful for about a week. What you actually need is someone who can read your codebase, tell you which of the three paths is cheapest and safest for your app, and then carry it out without breaking the thing your users rely on.
This guide is the framework we use at BrainFeed when a Xamarin app lands on our desk.
This article is for:
- Product owners and CTOs responsible for a Xamarin or Xamarin.Forms app that still has users
- Teams whose app store submissions have started failing
- Anyone comparing a .NET MAUI migration quote against a rebuild quote
This article is NOT for:
- Developers learning Xamarin as a career move. Learn .NET MAUI, Flutter, or React Native instead
- New apps. If you're starting from scratch, see our mobile app development cost breakdown for the frameworks that make sense in 2026
Where Xamarin stands in 2026
The short version: Xamarin is finished, and the deadlines that matter are the app stores', not Microsoft's.
- 1 May 2024 - Microsoft ended support for all Xamarin SDKs, including Xamarin.Forms, Xamarin.Android and Xamarin.iOS. No more security fixes, bug fixes or updates for new platform versions.
- Final platform targets - the last Xamarin SDKs target Android API 34 and Xcode 15 (iOS 17). They will never target anything newer.
- Apple - since April 2025, App Store uploads must be built with a newer Xcode and iOS SDK than Xamarin supports, and Apple raises that minimum every spring. In practice, a Xamarin.iOS app can't ship updates to the App Store any more.
- Google Play - existing apps must now target API 35 to stay visible to new users on newer Android devices, and from 31 August 2026 new apps and updates must target API 36 (with extensions available to 1 November 2026). A Xamarin.Android app tops out at API 34.
So the practical situation is this: your Xamarin app can keep running for the users who already have it installed, but you can't reliably ship updates to either store. The next time you need a bug fix, a security patch, or a change for a new iOS release, you'll hit a wall.
The three paths
Every Xamarin app we look at ends up on one of three paths. The right one depends on the state of the code, how much the app still has to change, and how long the business needs it.
Path 1: Keep it alive for a defined period
What it is: a developer stabilises the build, fixes what's broken, and keeps the app running for existing users while you plan a proper migration or retire the app.
When it makes sense:
- The app is being retired within 6 to 12 months
- It's an internal or enterprise app distributed outside the public stores (MDM, sideloading), where store SDK rules don't block you
- You need breathing room to budget a migration properly
What it can't do: it can't get you past the store SDK requirements, and it doesn't fix the security exposure of running an unsupported stack. Treat it as a bridge with an end date, never as a strategy.
Path 2: Migrate to .NET MAUI
What it is: move the app to .NET MAUI, Microsoft's successor to Xamarin.Forms. Your C# business logic, view models and much of your XAML carry over. Custom renderers, platform-specific code and third-party libraries are where the real work sits.
When it makes sense:
- The app is built on Xamarin.Forms with a reasonably clean MVVM structure
- Your team, or the team that will own the app, works in C# and .NET
- The app shares code or libraries with a .NET backend
- The UI and feature set are broadly right and don't need a redesign
What bites you:
- Custom renderers have to be rewritten as MAUI handlers. An app with dozens of them is closer to a partial rebuild than a migration.
- Abandoned libraries. Plenty of Xamarin-era NuGet packages never got MAUI versions. Each one needs a replacement or a rewrite.
- Target the current MAUI version. A major .NET MAUI release is only supported for about 6 months after the next one ships, so migrate straight to .NET 10 (the current LTS, supported to November 2028) rather than an older release you'll have to upgrade again next year.
Microsoft's .NET Upgrade Assistant handles the project-file conversion. It doesn't handle renderers, libraries or testing, which is where most of the time goes.
Path 3: Rebuild in Flutter or React Native (or native)
What it is: a new app, built on a current cross-platform framework or natively, reusing your API, data model and product knowledge but not the Xamarin code.
When it makes sense:
- The Xamarin code is messy, heavily customised with renderers, or poorly understood
- The app needs a significant redesign or new features anyway
- Your team, or your hiring market, is stronger in Dart or JavaScript/TypeScript than C#
- The app is small enough that rebuilding costs about the same as migrating
What bites you: rebuilds always find the business rules nobody wrote down. Budget time to extract them from the old code before the new app is designed, not after users report something missing.
How to decide
Route by the state of the app, not by which framework sounds more modern:
- App being retired within a year, or distributed privately → Keep it alive, with a written end date
- Xamarin.Forms, clean MVVM, C# team, UI still fits → Migrate to .NET MAUI
- Many custom renderers or native bindings → get a renderer and library audit before choosing; it often tips the decision to a rebuild
- Heavy redesign or big new features planned → Rebuild
- No one on the team understands the codebase → Rebuild, after a short discovery to extract the business logic
- Shared .NET libraries with your backend → lean MAUI, because that code reuse is real value
If two paths look close, the tiebreaker is who owns the app for the next five years. Pick the stack that team can hire for and maintain.
What to look for in a Xamarin developer in 2026
Because the job is a decision followed by a migration or rebuild, the skills that matter are different from a 2019 job description.
Must have:
- Hands-on Xamarin.Forms and .NET MAUI experience, including at least one completed Xamarin-to-MAUI migration they can talk through
- Comfort with Xamarin.Android and Xamarin.iOS internals: custom renderers, platform-specific code, native bindings
- Current knowledge of App Store and Google Play submission rules, including signing, provisioning and target SDK requirements
- The judgement to say "don't migrate this, rebuild it" when that's the honest answer
Strong signals:
- They ask for repository access and a codebase audit before quoting a fixed price
- They produce a written inventory of renderers, libraries and platform code with a replacement for each
- They have Flutter or React Native experience too, so the recommendation isn't biased toward the only thing they know
- They set up CI builds early, so the app can be built by anyone, not just one laptop
Red flags:
- A fixed migration quote with no code review
- "Upgrade Assistant does most of it" as the whole plan
- Proposing to keep shipping Xamarin updates indefinitely
- No plan for testing on real iOS and Android devices before release
Hiring model: freelancer, in-house, or agency
- Freelancer - fine for Path 1 (stabilise and keep alive) on a small app. Risky for a full migration, because the knowledge leaves with one person.
- In-house hire - makes sense only if the app is core to the business and you'll keep a mobile team afterwards. Hiring specifically for Xamarin in 2026 is hard, and the skill has a short shelf life.
- Agency or dedicated team - usually the best fit for a migration or rebuild: a senior developer to audit and decide, and enough people to migrate, test and release on a fixed timeline, with the build documented at the end so you aren't dependent on anyone.
Whichever you choose, make the first engagement a paid audit, not the whole project. A few days reviewing the codebase will tell you which path you're on and give you a quote you can trust.
What drives the cost
We won't publish a single number, because two Xamarin apps with the same screen count can differ by several times in effort. What moves the price:
- Number of custom renderers and platform-specific features - the biggest driver for a MAUI migration
- Third-party libraries without MAUI equivalents - each one is a replacement or a rewrite
- Test coverage - no automated tests means more manual regression testing on real devices
- Backend changes - a rebuild often exposes API gaps the old app worked around
- Design scope - a like-for-like migration is far cheaper than a migration plus redesign
For a sense of full rebuild budgets, our mobile app development cost guide breaks down 2026 ranges by app complexity and platform.
FAQ
Is Xamarin still supported in 2026?
No. Microsoft ended support for all Xamarin SDKs, including Xamarin.Forms, on 1 May 2024. There are no security fixes or updates, and the final Xamarin SDKs only target Android API 34 and Xcode 15, which is below what the App Store and Google Play now require for updates.
Can I still publish a Xamarin app to the App Store or Google Play?
Not reliably. Apple requires uploads to be built with a newer Xcode and iOS SDK than Xamarin supports, and Google Play requires app updates to target API 36 from 31 August 2026, while Xamarin stops at API 34. Existing installs keep working, but shipping updates effectively requires migrating to .NET MAUI or rebuilding.
Should I migrate from Xamarin to .NET MAUI or rebuild the app?
Migrate to .NET MAUI if the app uses Xamarin.Forms with clean MVVM code, your team works in C#, and the UI doesn't need a redesign. Rebuild in Flutter or React Native if the code relies heavily on custom renderers, nobody understands it well, or you're planning major changes anyway. A short codebase audit usually makes the answer clear.
How long does a Xamarin to .NET MAUI migration take?
It depends mostly on custom renderers and third-party libraries rather than screen count. A clean Xamarin.Forms app can move in a few weeks, while an app with heavy platform-specific code can take as long as a rebuild. Get a renderer and library inventory before accepting any timeline.
What skills should a Xamarin developer have in 2026?
Xamarin.Forms plus hands-on .NET MAUI migration experience, knowledge of Xamarin.Android and Xamarin.iOS internals such as custom renderers and bindings, current app store submission requirements, and ideally Flutter or React Native experience so their recommendation isn't limited to one stack.
Is .NET MAUI the same as Xamarin?
.NET MAUI is the successor to Xamarin.Forms. It keeps the C# and XAML approach, uses a single project for Android, iOS, macOS and Windows, and replaces Xamarin's custom renderers with handlers. It runs on current .NET releases, with .NET 10 as the long-term support version supported until November 2028.
Stuck with a Xamarin app that can't ship updates? We take on all three paths: stabilising an existing Xamarin app, migrating it to .NET MAUI, or rebuilding it in Flutter or React Native. It starts with a short codebase audit so you know which one fits before you commit to a budget. See our mobile app development services.
