Hire a Dedicated Xamarin Team for App Maintenance and .NET MAUI Migration
Microsoft ended official Xamarin support in May 2024. If your iOS or Android app still runs on Xamarin.Forms or Xamarin.Native, you probably know the pressure: store submission requirements keep moving, third-party libraries stop getting patches, and finding engineers who actually understand Xamarin internals gets harder every quarter.
At Siblings Software, we assemble dedicated Xamarin teams that do two things well. First, we stabilize and maintain your existing Xamarin apps so they keep passing store reviews and serving users. Second, we plan and execute the migration to .NET MAUI at a pace that fits your budget and risk tolerance.
We are a software outsourcing company based in Cordoba, Argentina, and we have been building mobile and cross-platform teams since 2014. Our Xamarin squads include senior C# engineers, QA leads, and delivery managers who work in your time zone, use your tools, and join your standups.
The Xamarin situation in 2026: what you are actually dealing with
Here is the honest picture. Xamarin is no longer receiving security patches, bug fixes, or tooling updates from Microsoft. The final Xamarin SDKs are pinned to Android API 34 and Xcode 15-era targets. That means every new Apple or Google OS release creates a potential compatibility gap you have to work around.
But "end of support" does not mean "end of your app." Thousands of production apps still depend on Xamarin. Many of them generate real revenue, serve real customers, and cannot afford a rushed rewrite. The practical question is not whether to move off Xamarin, but how fast and how safely.
This is exactly where a specialized team makes the difference. You need people who:
- Know how to keep Xamarin apps compiling against newer SDK targets when official tooling does not cooperate.
- Can identify which third-party NuGet packages have MAUI equivalents and which need replacement.
- Understand the differences between Xamarin.Forms renderers and MAUI handlers at a structural level, not just from reading blog posts.
- Have actually shipped .NET MAUI apps to production, not just built demos.
Our teams have handled Xamarin codebases ranging from 30K to 400K lines of shared C#. We know where the migration pain points hide: custom renderers, platform effects, dependency injection containers that do not map cleanly, and third-party SDKs (payment processors, analytics, push notification services) that require native bridging.
What your Xamarin team will actually deliver
We do not sell "Xamarin developers" as interchangeable resources. We build teams around what your project actually needs. Here are the most common engagement shapes we see:
Legacy maintenance and stabilization
Your app works, but it is getting harder to maintain. Crash rates are creeping up, store submissions take multiple attempts, and nobody on your team wants to touch the Xamarin codebase anymore. We take over the maintenance burden: fixing crashes, updating dependencies, keeping CI/CD pipelines functional, and handling store review cycles for both iOS and Android.
Phased .NET MAUI migration
The full rewrite approach is risky and expensive. We prefer module-by-module migration: start with the least complex screens, validate them in production alongside the existing Xamarin code, and gradually shift the entire app. Your users never notice because both platforms run in parallel until the cutover is complete. We follow Microsoft's official migration guidance and supplement it with patterns we have refined across multiple real migrations.
New feature development
Sometimes you cannot wait for migration to finish before shipping a feature your business needs. We build new features in whichever layer makes sense: Xamarin if the feature ships next month, MAUI if it is three months out and migration is underway. The point is keeping your product competitive while the technical transition happens underneath.
Performance and quality engineering
Slow startup times, memory leaks on older Android devices, inconsistent behavior between iOS versions. These are symptoms of accumulated technical debt, and they get worse when the framework itself is no longer patched. Our QA and performance engineers instrument your app with crash analytics, set up performance baselines, and systematically reduce the issues that hurt your store rating.
Who typically hires a Xamarin team (and why)
Not every company needs this service. But if any of these scenarios sound familiar, we should talk:
Your internal team moved on. The engineers who built the Xamarin app left or shifted to other projects. Nobody remaining wants to own the codebase, but the app still serves paying customers.
Store submissions keep failing. Apple's minimum SDK requirements and Google's target API level mandates tighten every year. Your Xamarin tooling is falling behind, and each submission cycle becomes a firefight.
You need migration expertise. Your team knows C# well, but nobody has actually migrated a production Xamarin app to .NET MAUI. You want people who have done it before and know which shortcuts work and which ones create problems.
You are scaling and cannot hire fast enough. Recruiting Xamarin developers in the US or Western Europe is increasingly difficult because the talent pool has shrunk since end-of-support. A nearshore team lets you scale without competing for a tiny local market.
You want a bridge to MAUI without stopping current work. Your product cannot afford a feature freeze while migration happens. You need a team that can run two tracks: maintaining the current app and building toward the new platform simultaneously.
Compliance or audit pressure. Regulated industries (healthcare, finance) may flag unsupported frameworks as a security risk. You need a documented migration plan and evidence of active remediation.
How we assemble your Xamarin team
We keep this straightforward. Most teams are productive within two weeks of the first conversation.
Step 1-2: Discovery and team matching
We review your codebase (or at minimum your architecture and dependency list), understand the current state, and identify what mix of skills you need. A maintenance-heavy engagement might only need two engineers and a part-time QA. A full migration might require a tech lead, three C# engineers, a QA lead, and a delivery manager.
Step 3: Onboarding sprint
Your team gets access to your repos, tooling, and communication channels. We set up CI/CD integration (Azure DevOps, GitHub Actions, or whatever you use), establish coding standards, and run our first code review pass. By the end of week two, engineers are submitting pull requests against your codebase.
Steps 4-5: Delivery and iteration
From here, it is regular sprint work. Weekly demos, shared KPI dashboards, and retrospectives. We track velocity, crash rates, store submission success, and migration progress (if applicable). The team scales up or down based on what the project needs, no long-term lock-in contracts.
Pricing and engagement models
We are transparent about costs. Here is what the market looks like and where we fit:
Our rates
Nearshore rates from Argentina: $35 to $65 per hour, depending on the seniority mix. A 4-person squad (tech lead, two mid-senior C# engineers, and a QA engineer) typically runs between $18,000 and $28,000 per month.
We offer monthly and quarterly engagement terms. No long-term lock-in, though most Xamarin engagements run 6-12 months because migration projects take time to do properly.
What is included
- A delivery manager who handles sprint planning, stakeholder updates, and team logistics.
- QA built into the team, not bolted on as an afterthought.
- CI/CD pipeline setup and maintenance.
- Weekly progress reports with velocity metrics.
- Access to our broader .NET and mobile engineering bench if you need to scale.
Compare this to hiring freelancers on a marketplace, where you get individual contributors but no delivery structure, no QA, and no migration roadmap. Or to hiring in-house, where a single senior Xamarin engineer in the US costs $150K-$200K annually before benefits and overhead.
Freelancers vs. in-house vs. a dedicated team: honest tradeoffs
Each model works for certain situations. Here is our candid take on when each makes sense:
Freelancers
Useful for one-off fixes or small tasks. The problem with Xamarin specifically is that the freelancer pool has shrunk considerably since end-of-support. Many strong Xamarin freelancers have already pivoted to MAUI or Flutter. For anything that takes more than a few weeks, you will likely need to manage the work yourself and deal with handoff risks.
In-house hires
The strongest option if you have ongoing mobile work beyond Xamarin. But recruiting Xamarin-experienced engineers takes 2-4 months in most US markets, and you are hiring for a skill set that is, by definition, sunsetting. It is a hard sell to candidates too. Many prefer roles that use current frameworks.
Dedicated team (our model)
The fit is strongest when you need sustained effort over several months: maintaining an app while migrating, or running dual-track development. You get a team that works as a unit, with built-in QA and delivery management, at nearshore rates. We are not the cheapest option and not the most expensive. We are the option that includes a migration plan.
Technical capabilities
Our engineers work across the full Xamarin and .NET MAUI stack. Here is a realistic inventory of what we bring:
Xamarin and C#
- Xamarin.Forms, Xamarin.Native (iOS and Android)
- MVVM patterns: Prism, MvvmCross, ReactiveUI, FreshMvvm
- Custom renderers, platform effects, dependency services
- SQLite, Realm, Entity Framework Core for local data
- Secure storage, biometrics, push notifications
.NET MAUI and migration tooling
- .NET MAUI handlers, platform-specific code patterns
- Migration from Xamarin.Forms to MAUI using the .NET Upgrade Assistant
- NuGet dependency auditing and replacement mapping
- CI/CD: Azure DevOps, GitHub Actions, App Center, TestFlight
- Testing: NUnit, xUnit, Appium, Xamarin.UITest
When a project also needs server-side work, we pull from our .NET engineering bench to add API or cloud infrastructure capacity without disrupting the mobile team.
Case study: stabilizing a healthcare app and launching the MAUI migration
The situation: A chronic care coordination platform serving 50,000+ patients across Argentina had a Xamarin.Forms app with a 3.8-star store rating. Bug fixes took six weeks to ship. Their internal mobile developer had left, and nobody remaining understood the Xamarin codebase. A major partnership with a health insurer was contingent on improving app reliability.
What we did: We placed a 5-person squad: tech lead, two C# engineers, a QA lead, and a delivery manager. The first month focused entirely on stabilization: we refactored the MVVM layer, cleaned up dependency injection, and added automated smoke tests via App Center. Crash rate dropped from 2.1% to 0.3%.
In months two and three, we launched dual-track delivery. Track one continued shipping bug fixes and minor features to the production Xamarin app. Track two built a .NET MAUI proof of concept targeting tablet users (a new clinician tool the insurer required). Both tracks shared a single backlog and sprint cadence.
Results after three months:
- Store rating improved from 3.8 to 4.5 stars.
- Patient task completion increased 22%.
- Shared code complexity reduced 28% (measured by cyclomatic complexity).
- Regression verification went from two days to two hours.
- The client extended the engagement to co-build additional clinician tools on MAUI.
Engagement details
- Team: 5 people (tech lead, 2 Xamarin/C# engineers, QA lead, delivery manager)
- Duration: 3 months initial, extended to 9+
- Work: Stabilization, feature delivery, .NET MAUI proof of concept
- Integration: Joined client standups, used their Azure DevOps, coordinated with their compliance team
Read more about our delivery approach in our case studies section.
Risks of outsourcing Xamarin work (and how we handle them)
Outsourcing mobile development has real risks. Pretending they do not exist would not help you make a good decision. Here is what typically goes wrong and what we do about it:
Knowledge gaps about your business
An external team does not know your product the way your internal team does. We mitigate this with a structured onboarding process: we spend the first week doing nothing but learning your codebase, your users, and your business constraints. We also pair program with your engineers (if you have them) during the first sprint.
Communication overhead
Distributed teams need deliberate communication practices. We assign a delivery manager who owns the communication layer: daily async updates, weekly demos, and a shared Slack or Teams channel. Our Argentina time zone means 6-8 hours of real-time overlap with US East Coast teams.
Vendor lock-in
If we disappeared tomorrow, you should still be able to ship your app. We use your repos, your CI/CD, and your accounts. We document decisions, maintain architecture records, and deliver handover materials. Everything we build lives in your infrastructure, not ours.
Migration quality
A bad migration creates more problems than it solves. We validate every migrated module with automated regression tests before it reaches production. Parallel release tracks mean the old Xamarin app keeps running until the MAUI version proves stable. No big-bang cutover, no crossed fingers.
Three things clients usually get wrong about Xamarin migration
After working on a dozen migration projects, patterns emerge. These are the most common misconceptions we hear during initial calls:
Underestimating custom renderer complexity
If your Xamarin.Forms app has 10+ custom renderers, the migration is not going to be straightforward. MAUI uses a handler architecture that is fundamentally different. Each renderer needs to be re-evaluated and rewritten. Budget for this work explicitly; it is where most timeline estimates go wrong.
Assuming third-party libraries "just work"
Some popular Xamarin NuGet packages have MAUI equivalents. Many do not. Payment SDKs, analytics tools, and push notification libraries may need replacement or native bridging. We audit your entire dependency tree before estimating the migration, because this is the step most teams skip and later regret.
Trying to migrate and add features simultaneously
It is tempting to combine the migration with new feature work. In practice, this creates merge conflicts between two moving targets and slows both streams. We recommend a clean separation: migrate existing functionality first, then build new features on the MAUI foundation. Dual-track delivery handles this without a feature freeze.
Frequently asked questions
Related services
Xamarin projects often overlap with other parts of our practice. Here are the most common combinations:
When your Xamarin mobile app connects to .NET APIs or Azure services, we extend the team with server-side C# engineers.
For projects where the work spans desktop, mobile, and cloud all in C#, our cross-platform C# engineers bring consistency across platforms.
Hire a cross-platform app team
If migration from Xamarin leads you to evaluate Flutter or React Native instead of MAUI, our cross-platform practice covers all three options.
Need individual Xamarin developers instead of a full team? Our staff augmentation model places engineers directly into your existing squad.
An overview of everything we do with Xamarin and .NET MAUI, from consulting to full project delivery.
Browse our full catalog of technology-specific dedicated teams across 40+ frameworks and languages.
OUR STANDARDS
Xamarin development, done right.
We measure ourselves by outcomes, not activity. Every sprint should make your app more stable, your migration closer to complete, or your team more capable. If we cannot point to concrete progress, something is wrong and we will say so.
What this looks like in practice:
- We track crash-free session rates, store rating trends, and build success percentages as first-class metrics.
- Every migration module gets automated regression coverage before it reaches production.
- We document architectural decisions so your team can maintain the codebase independently if the engagement ends.
- We flag problems early. If a timeline looks unrealistic or a technical approach is not working, you hear about it in the next standup, not the next quarterly review.
Code quality, test coverage, and honest communication are not differentiators. They are the minimum. The differentiator is that we have done this specific work before and know where the risks hide.
Contact Siblings Software Argentina
Tell us about your Xamarin project and we will outline a plan.