Xamarin Migration to .NET MAUI, Flutter or React Native

What end of support means for a Xamarin app

Your Xamarin app did not stop working when support ended. What stopped is everything around it. Apple regularly raises the minimum Xcode and SDK versions it accepts for uploads, Google Play raises its target API level every year, and Xamarin no longer receives updates to keep pace with either. Sooner or later a routine bug fix cannot be submitted because the toolchain is too old for the store.

Third party libraries are moving on as well. Firebase, payment, mapping and analytics vendors have been dropping Xamarin bindings, so security patches and new OS features stop arriving. Hiring is harder too, since few developers want to maintain a retired framework. Tepia usually advises clients to plan the migration before a store deadline forces it, so the work can include long requested fixes instead of a rushed port.

Signs the migration should move to the top of your list:

• A store submission has already failed, or a warning email from Apple or Google names a coming requirement.
• A payment, mapping or analytics SDK you rely on has published its last Xamarin version.
• Builds only work on one developer’s older Mac with a pinned Xcode version.
• New features keep getting deferred because nobody wants to touch the renderers.

Choosing the target: MAUI, Flutter, React Native or native

The right target depends on whether you want to keep your C# code, who will maintain the app, and how custom the interface is. Tepia lays the options out side by side for each client:

MAUI is the shortest path for most line of business apps, but not automatically the best. If the Xamarin app was already being outgrown, a rewrite in Flutter or React Native can deliver the redesign and the migration in one project. Our React Native vs Flutter vs native guide and rebuild or refactor page go deeper on that call.

What a .NET MAUI migration actually involves

Moving from Xamarin.Forms to MAUI is closer to a renovation than a recompile. Tepia starts with an inventory of the codebase and works through the known changes:

• Project structure. Separate iOS, Android and shared projects collapse into a single MAUI project with platform folders, and startup moves to a builder pattern.
• Custom renderers. Each renderer is rewritten as a handler or mapped through a compatibility layer, and Tepia uses the rewrite to drop renderers the new controls make unnecessary.
• Essentials and messaging. Xamarin.Essentials features now ship inside MAUI under new namespaces, and MessagingCenter gives way to the messenger in the .NET Community Toolkit.
• Dependencies. Every NuGet package is checked for current .NET support. Abandoned ones are replaced, and native SDK bindings for Firebase, maps or payments are updated.
• Performance. Startup time, list scrolling and memory are measured against the old app on the same devices, since layout behavior differs between the two frameworks.

Microsoft’s .NET Upgrade Assistant helps with project files, but most of the effort sits in renderers, third party controls and testing. Tepia has deep .NET experience across web and mobile, including legacy .NET modernization.

Keeping users, data and store listings through the switch

A migration fails if users notice it for the wrong reasons. Tepia keeps the same bundle identifier, Android package name and signing keys, so the new build ships as an update to the existing listing with its ratings and history. Version numbers continue upward, and push notification tokens are registered again on first launch.

On the device, the new app finds and migrates the old SQLite database, preferences and secure storage entries, whose locations and key names can differ between frameworks. Deep links and universal links keep working. Rollout uses phased release on the App Store and staged rollout on Google Play, with the Xamarin code kept on a maintenance branch until adoption is high enough to retire it.

How Tepia approaches Xamarin migration

Migrations follow the six Tepia phases, with a parity checklist running through all of them.

1. Discovery: a code and dependency audit, a review of store deadlines and third party SDKs, and interviews with users about what to fix while the app is open. The Investigation Summary recommends a target, and User Stories capture every existing feature for the parity list.
2. Design: a design questionnaire and style guide decide whether the app keeps its look or gets a refresh; wireframes cover any screens that change.
3. Development and Testing: shared logic moves first, then screens in priority order. Alpha compares old and new builds side by side, and Beta goes to real users through TestFlight and Play testing tracks, with test plans for parity, data migration and performance.
4. Training: your developers get a walkthrough of the new architecture, build pipeline and release process, so the team can own it.
5. Launch: phased store release, on device data migration, monitoring of crash rates against the old version, and support reps on hand during rollout.
6. Support: bug tracking, framework upgrades on the .NET or Flutter release cycle, and the feature requests that were parked during the migration.

Typically Discovery takes 1 to 3 months, often less with a clean codebase, and development and QA 2 to 6 months. Read more about the Tepia process or send us your Xamarin app for an assessment.

Frequently asked questions