Xamarin & PhoneGap Are Dead: The Enterprise Mobile Migration Playbook (2026)

Your Xamarin app just got rejected from the App Store

It happened to one of our clients in late 2025. A routine update to their Xamarin.Forms insurance claims app was rejected by Apple because the app was built with an Xcode SDK version that no longer met App Store submission requirements. The app worked fine. Users were happy. But Apple’s automated review did not care about user satisfaction. It cared about SDK versions.

This will happen to every Xamarin app eventually. The only variable is when.

PhoneGap teams hit this wall earlier. Adobe pulled the plug in 2020, and the Cordova ecosystem has been slowly decaying since. Plugin authors have moved on. The WebView bridge that PhoneGap relied on has not kept pace with mobile OS changes. Apps still run, but they are frozen in place.

If you are reading this, you probably already know migration is necessary. The question is: migrate to what, and how?

The mobile framework landscape in 2026

The cross-platform mobile framework market has consolidated around three viable options for enterprise development:

.NET MAUI

Microsoft’s official successor to Xamarin.Forms. Ships as part of the .NET ecosystem (.NET 10+), uses C# and XAML, and targets iOS, Android, macOS, and Windows.

Strengths:

• Lowest migration friction for Xamarin.Forms apps (same language, similar patterns)
• Single project structure (replaces the multi-project Xamarin approach)
• Deep integration with Visual Studio and the .NET ecosystem
• Good for apps that share code with .NET backends

Limitations:

• Smaller community ecosystem than React Native
• Fewer third-party UI component libraries
• MAUI’s maturity is still catching up to Xamarin.Forms in some areas (particularly around performance on older Android devices)
• Hiring MAUI developers is harder than hiring React Native developers

React Native

Meta’s cross-platform framework. Uses JavaScript/TypeScript and React, with native rendering.

Strengths:

• Largest cross-platform community ecosystem
• Extensive library of well-maintained plugins and components
• Strong hiring market (React skills are widespread)
• New Architecture (Fabric, TurboModules) has significantly improved performance
• Expo framework simplifies build and deployment workflows

Limitations:

• Language change from C# (for Xamarin teams) or requires rethinking from web-based (for PhoneGap teams)
• Bridge-based architecture can add complexity for heavily native features
• Two build systems to maintain (Xcode for iOS, Gradle for Android)

Flutter

Google’s cross-platform framework using Dart. Included here for completeness, but not a primary recommendation for .NET-heavy organisations.

Strengths:

• Excellent rendering performance (Skia/Impeller engine)
• Strong widget library
• Good developer tooling

Limitations:

• Dart is not widely used outside Flutter
• Smaller enterprise ecosystem than React Native
• Does not share a language with .NET backends or web frontends
• Google’s long-term commitment to Flutter is a topic of ongoing discussion

For a detailed comparison of the two primary options, see our MAUI vs React Native comparison for enterprise teams.

How the four pillars apply to mobile migration

The same four-pillar framework we use for backend .NET modernisation applies to mobile migration, though the emphasis shifts.

Pillar 1: Language migration

For Xamarin.Forms to MAUI, the language stays the same (C#). The migration is primarily structural: project file format, namespace changes, Custom Renderers to Handlers, and XAML syntax updates. AI-assisted tooling handles much of this mechanical work.

For PhoneGap to React Native, there is a genuine language change. The HTML/CSS/JavaScript of PhoneGap becomes JSX/TypeScript of React Native. This is closer to a rewrite than a migration, though AI tooling can translate component structures and business logic patterns.

For Xamarin.Native (Xamarin.iOS and Xamarin.Android) to either target, the migration is more complex because Xamarin.Native used platform-specific APIs directly. The abstraction layer that Xamarin.Forms provided (and that MAUI continues) does not exist for Xamarin.Native apps.

Pillar 2: Platform modernisation

Mobile platform modernisation means updating the build and deployment pipeline. Xamarin used MSBuild with Xamarin-specific targets. PhoneGap used its own CLI.

For MAUI: The build system is .NET CLI based. CI/CD integrates with GitHub Actions or Azure DevOps. App signing and distribution can use dotnet publish with appropriate provisioning profiles.

For React Native: The build system uses Metro bundler, Xcode (iOS), and Gradle (Android). Expo’s EAS Build service simplifies CI/CD significantly. We recommend Expo for most enterprise React Native projects because it abstracts away the native build complexity.

Pillar 3: Architecture modernisation

Mobile architecture modernisation typically involves:

• Moving from a monolithic app architecture to a modular one (feature modules, navigation restructuring)
• Adopting modern state management (MAUI: MVVM with CommunityToolkit; React Native: Redux Toolkit, Zustand, or React Query)
• Implementing offline-first data patterns if the original app had limited offline support
• Redesigning the navigation structure (Xamarin.Forms navigation to .NET MAUI Shell, or to React Navigation)

Pillar 4: Integration modernisation

The mobile app’s integration layer (API calls, push notifications, authentication, analytics) often needs updating during migration:

• REST API clients need regenerating for the new framework
• Push notification registration changes (MAUI uses platform-specific handlers; React Native uses libraries like react-native-push-notification or Expo Notifications)
• Authentication flows may need updating (MSAL for MAUI, or react-native-app-auth for React Native)
• Third-party SDKs (analytics, crash reporting, feature flags) need framework-specific equivalents

Xamarin.Forms to .NET MAUI: what changes

The Xamarin.Forms to MAUI migration path is the most documented and has the most tooling support. The core changes:

Project structure

Xamarin.Forms solutions typically had a shared project plus platform-specific projects (.iOS, .Android, .UWP). MAUI uses a single project with platform-specific folders.

Custom Renderers to Handlers

This is the biggest breaking change. Xamarin.Forms used Custom Renderers to customise how controls appeared on each platform. MAUI replaces them with Handlers, which have a different (simpler) architecture.

// BEFORE: Xamarin.Forms Custom Renderer
[assembly: ExportRenderer(typeof(RoundedEntry), typeof(RoundedEntryRenderer))]
namespace MyApp.iOS.Renderers
{
    public class RoundedEntryRenderer : EntryRenderer
    {
        protected override void OnElementChanged(
            ElementChangedEventArgs<Entry> e)
        {
            base.OnElementChanged(e);
            if (Control != null)
            {
                Control.Layer.CornerRadius = 10;
                Control.Layer.BorderWidth = 1;
                Control.Layer.BorderColor = UIColor.Gray.CGColor;
            }
        }
    }
}

// AFTER: .NET MAUI Handler
namespace MyApp.Handlers
{
    public partial class RoundedEntryHandler : EntryHandler
    {
        public static IPropertyMapper<IEntry, RoundedEntryHandler>
            Mapper = new PropertyMapper<IEntry, RoundedEntryHandler>(
                EntryHandler.Mapper)
        {
            [nameof(IEntry.Background)] = MapBackground
        };

        public RoundedEntryHandler() : base(Mapper) { }
    }

    // iOS-specific partial class
    public partial class RoundedEntryHandler
    {
        private static void MapBackground(
            RoundedEntryHandler handler, IEntry entry)
        {
            handler.PlatformView.Layer.CornerRadius = 10;
            handler.PlatformView.Layer.BorderWidth = 1;
            handler.PlatformView.Layer.BorderColor =
                UIColor.Gray.CGColor;
        }
    }
}

Claude Code handles the mechanical conversion from Renderer to Handler patterns. The structural change is well-defined, and the mapping is consistent. Human review focuses on verifying that the visual behaviour is identical on each platform.

XAML namespace changes

<!-- BEFORE: Xamarin.Forms XAML -->
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">

<!-- AFTER: .NET MAUI XAML -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">

Dependency injection

Xamarin.Forms used DependencyService or third-party containers. MAUI uses the built-in .NET DI container:

// BEFORE: Xamarin.Forms DependencyService
var locationService = DependencyService.Get<ILocationService>();

// AFTER: .NET MAUI built-in DI (register in MauiProgram.cs)
builder.Services.AddSingleton<ILocationService, LocationService>();
// Inject via constructor
public class MapViewModel(ILocationService locationService) { }

Syncfusion and Telerik component migration

Many enterprise Xamarin.Forms apps use Syncfusion or Telerik component suites. Both vendors have MAUI equivalents, but the APIs are not always identical:

• Syncfusion: Provides a migration guide and most components have MAUI equivalents. Some API changes exist (particularly in charting and scheduling components).
• Telerik: Has MAUI support through the Telerik UI for .NET MAUI suite. Component parity is good but check individual component support before planning migration.

Claude Code can handle the API renaming and namespace changes for these component libraries when given the migration documentation as context.

For the full technical walkthrough of Xamarin.Forms to MAUI, see our Xamarin to .NET MAUI migration guide.

PhoneGap/Cordova to React Native: what changes

PhoneGap to React Native is a more fundamental migration because the architectural model is entirely different.

From WebView to native rendering

PhoneGap apps are web applications (HTML, CSS, JavaScript) running inside a native WebView container. React Native renders native platform components directly. This is not a translation. It is a paradigm shift.

PhoneGap architecture:

JavaScript -> WebView -> Platform WebView Engine -> Screen

React Native architecture:

JavaScript -> React Native Bridge/JSI -> Native UI Components -> Screen

The consequence: PhoneGap UI code (HTML templates, CSS stylesheets) does not translate to React Native. The UI layer is effectively a rewrite. Business logic in JavaScript can be preserved and adapted.

Plugin architecture

PhoneGap plugins bridge JavaScript to native APIs via a standardised plugin interface. React Native modules serve the same purpose but with a completely different API.

Most PhoneGap plugins have React Native equivalents, but they are different libraries with different APIs:

Our recommendation: Use Expo-managed equivalents where available. The Expo ecosystem provides consistent APIs, automatic native module linking, and simplified build processes.

Business logic preservation

JavaScript business logic from PhoneGap apps can often be preserved during migration to React Native. API clients, data transformation functions, validation logic, and utility functions written in plain JavaScript transfer directly. The UI layer and plugin interfaces need rewriting.

Claude Code is effective at adapting JavaScript business logic to TypeScript (which we recommend for all new React Native projects) and restructuring it into React Native patterns (hooks, context providers, custom hooks for shared logic).

For the complete migration guide, see Migrating from Xamarin or PhoneGap to React Native.

How AI-assisted tooling fits into mobile migration

AI-assisted tooling applies differently to mobile migration than to backend .NET migration. The key differences:

Higher AI leverage for Xamarin to MAUI. The migration is mostly structural: namespace changes, Renderer-to-Handler conversion, project restructuring. These are well-defined patterns that Claude Code handles with high accuracy. We typically see 55-70% AI-authored code in Xamarin to MAUI migrations.

Lower AI leverage for PhoneGap to React Native. The paradigm shift from WebView to native rendering means more of the UI layer is a rewrite rather than a translation. Claude Code helps with business logic adaptation and component scaffolding, but the visual design and interaction patterns need human design decisions. We typically see 40-55% AI-authored code in PhoneGap to React Native migrations.

Device testing cannot be automated by AI. Regardless of the migration path, every screen and interaction must be tested on physical iOS and Android devices. AI tools can generate test code and automate some verification, but the final visual and interaction quality check is a human activity.

CLAUDE.md for mobile projects

# Project: ClaimsApp Migration (Xamarin.Forms to MAUI)

## Target
- Source: Xamarin.Forms 5.x
- Target: .NET MAUI (.NET 10)
- Platforms: iOS 17+, Android 14+

## Conventions
- MVVM with CommunityToolkit.Mvvm
- Built-in DI (no DependencyService)
- Shell navigation (replace NavigationPage)
- File-scoped namespaces, primary constructors

## Migration rules
- Custom Renderers -> Handlers
- DependencyService.Get<T>() -> constructor injection
- Device.RuntimePlatform checks -> #if IOS / #if ANDROID
- MessagingCenter -> WeakReferenceMessenger
- Xamarin.Essentials -> Microsoft.Maui.Essentials (namespace change only)

## Component library
- Syncfusion Xamarin.Forms -> Syncfusion .NET MAUI
- Follow Syncfusion migration guide for API changes

## Do not
- Change any business logic
- Redesign screens (visual parity is the goal)
- Change API contracts or endpoints
- Remove platform-specific customisations

App Store and Play Store considerations

Migration is not complete until the new app is successfully submitted to both stores.

Apple App Store:

• Apps must be built with a recent Xcode SDK (Apple updates the requirement annually)
• MAUI apps use the current .NET iOS SDK, which targets the latest Xcode
• React Native apps (especially via Expo) track Xcode requirements closely
• Privacy nutrition labels must be updated if the migration changes data collection

Google Play Store:

• Apps must target a recent Android API level (Google updates annually)
• Both MAUI and React Native target current API levels
• The Play Store requires new apps to use Android App Bundles (AAB) rather than APKs
• Data safety forms must be reviewed after migration

Both stores:

• If the migration changes the app’s bundle identifier or signing certificate, it is treated as a new app (losing existing ratings and reviews)
• Preserve the same bundle identifier and signing to maintain continuity
• Consider a phased rollout (10% of users first) to catch issues before full deployment

What we have seen in practice

[CLIENT EXAMPLE: Insurance company, Xamarin.Forms claims app with 52 screens, Syncfusion components, offline data sync. Migrated to .NET MAUI over 6 weeks. Custom Renderer to Handler migration was the most time-consuming step (18 custom renderers). Syncfusion component migration was smoother than expected because the vendor’s MAUI APIs closely matched the Xamarin versions. AI-assisted tooling handled approximately 60% of code changes. Key lesson: start the App Store submission process early because Apple’s review for migrated apps can take longer than expected.]

[CLIENT EXAMPLE: Field services company, PhoneGap app for job scheduling with camera capture and offline storage, ~20k LOC JavaScript. Migrated to React Native with Expo over 5 weeks. Business logic (API clients, job scheduling algorithms, validation rules) was preserved and converted to TypeScript. UI was rebuilt in React Native components. Push notifications reimplemented using Expo Notifications. Total AI-authored code: ~55%. Key lesson: the Expo ecosystem simplified the build pipeline dramatically compared to the old PhoneGap build process.]

[CLIENT EXAMPLE: Property management company, Xamarin.Native app (separate Xamarin.iOS and Xamarin.Android projects) with 35 screens and heavy use of platform-specific APIs (camera, document scanning, Bluetooth for smart locks). Assessed for MAUI migration but the extensive Xamarin.Native code would have required near-complete rewrite regardless of target. Migrated to React Native instead, treating it as a rebuild with the existing app as a specification. 10-week timeline. AI-assisted development used for component scaffolding and API client generation. Key lesson: for Xamarin.Native apps, evaluate React Native even if the team’s primary expertise is C#, because the migration effort to MAUI is comparable.]

Choosing your migration path

The decision framework is simpler than it appears:

Choose MAUI when:

• You have a Xamarin.Forms app (not Xamarin.Native)
• Your team’s core expertise is C# and .NET
• You share significant code between mobile and backend
• You need Windows desktop support alongside mobile
• The app uses Syncfusion or Telerik components with MAUI equivalents

Choose React Native when:

• You have a PhoneGap/Cordova app (no direct MAUI migration path)
• You have a Xamarin.Native app (migration effort is comparable either way)
• Your team has JavaScript/TypeScript expertise or is willing to invest in it
• You want access to the largest cross-platform ecosystem of libraries and components
• Long-term developer hiring is a priority

Choose neither (consider a rebuild) when:

• The app’s functionality has fundamentally changed since it was built
• The existing app architecture is not worth preserving
• The app needs a complete redesign alongside the technical migration
• See our Modernise, Rebuild, or Replace guide for the full decision framework

Getting started

If your enterprise mobile apps run on Xamarin or PhoneGap, the first step is assessing what you have. Not all apps need the same migration path, and some may not need migration at all (if they are candidates for retirement).

Our Mobile Migration Assessment is a structured evaluation that covers:

• Current app architecture and complexity analysis
• Migration path recommendation (MAUI, React Native, rebuild, or retire)
• Timeline and effort estimate for each viable path
• App Store compliance risk assessment
• Recommendations for build and deployment pipeline

Book a free Mobile Migration Assessment consultation to discuss your specific situation.

For the business and compliance risks of delaying migration, see Running Unsupported Xamarin or PhoneGap in Production?

For IP considerations when using AI tools in your migration, see Who Owns AI-Written Code?

Further reading

This guide is the hub for our mobile migration content cluster:

• Xamarin to .NET MAUI Migration Guide: step-by-step technical walkthrough
• Migrating from Xamarin or PhoneGap to React Native: when and how to make the move
• .NET MAUI vs React Native in 2026: honest comparison for enterprise teams
• Running Unsupported Xamarin or PhoneGap in Production?: risk assessment
• Modernise, Rebuild, or Replace: general decision framework
• Signs Your Legacy System Is Costing You More Than You Think: understanding hidden costs