Migrating from Xamarin, Cordova or Ionic — what your app is really up against and where to move it

An app written a few years ago in Xamarin, Cordova or Ionic often works without a hitch. People use it, the backend responds, and nobody sees a reason to change anything. The trouble starts when a new version has to go out: to fix a bug, add a feature or meet the next store requirement.

These three technologies tend to get lumped together, but they are in very different situations. Xamarin is out of support. Cordova is still developed, but the risk sits in its plugins. Ionic Framework lives on, while its paid services are ending. That determines whether migrating from Xamarin, Cordova or Ionic has to start now, and how big the job will be.

Xamarin: you can no longer ship a new version to the stores

Microsoft ended support for all Xamarin SDKs, including Xamarin.Forms, on 1 May 2024. The final versions Xamarin targets are Android API 34 and Xcode 15. Store requirements have moved on since then:

The app doesn’t vanish from phones. Anyone who has installed it can keep using it. That is exactly what makes the situation deceptive: everything looks fine until the day you need an urgent fix, because a payment provider changed its API or a security flaw came to light. Then it turns out there is no release path, and the migration starts under time pressure. We cover the consequences of the Google Play deadline in our article on why apps disappear from the store after the target API deadline.

So with Xamarin the question isn’t “should we migrate”, but “where to and when”.

Cordova: the project is alive, the risk sits in the plugins

Contrary to popular belief, Cordova isn’t dead. cordova-android 15, released in March 2026, raised the target SDK to 36, and cordova-ios got its 8.1.1 release in July 2026. The framework alone doesn’t force you to leave. Often it is enough to bring the platforms up to current versions.

The problem is plugins: they hold the native code, and login, payments, notifications and camera access all depend on them. Some haven’t had a release in years. The next test is 16 KB memory pages: from 1 February 2027, Google Play won’t accept updates that don’t support them. Cordova itself contains no native libraries, but plugins can bring them in, and .so libraries compiled with the old alignment block the release.

You can check this on a built package: APK Analyzer in Android Studio flags issues in its Alignment column, and zipalign -c -P 16 -v 4 app.apk confirms the result. If a key plugin fails and nobody is developing it, you have three options: your own fork, a replacement or a migration.

Ionic: the framework stays, the paid services are ending

Two things need separating here. Ionic Framework and Capacitor remain open source and are still maintained. The end applies to the commercial products. Appflow (builds and live updates) stays available until 31 December 2027, while Identity Vault, Auth Connect, Secure Storage and Ionic Portals are no longer sold and their maintenance is being phased out. If your release process or login relies on any of them, you need a replacement plan even if the rest of the app is in good shape.

The oldest projects on Ionic 1 are a separate category. They run on AngularJS, whose support ended at the close of 2021, so in practice the UI layer has to be rewritten anyway.

Where to move your app

The shortest route usually leads to the successor of the same technology. It isn’t always the best one, though.

.NET MAUI and .NET for Android/iOS. Microsoft stresses that projects don’t have to be rewritten, but they do have to move to the SDK-style format, and the upgrade tool doesn’t finish the job: according to the documentation, most cases need additional effort. Custom Xamarin.Forms renderers can be kept for a transition period but ultimately move to the handler model, and libraries with no .NET version have to be replaced. NuGet packages with their own .so libraries can also keep blocking the 16 KB requirement, even when the framework itself meets it.

It is also worth pricing in further maintenance. MAUI has a short cycle: a version gets support for at least 6 months after its successor ships, and the currently supported MAUI 10 runs until 11 May 2027. An annual upgrade has to be in the budget.

Capacitor. This is the gentlest way out of Cordova. Your web code stays, the app ID carries over from config.xml, and Capacitor can work alongside Cordova plugins for a while. The official guide recommends starting with a plugin audit: some will turn out to be unnecessary and others have equivalents, though not always with the same feature set. Capacitor 8 requires Xcode 26, Android Studio 2025.2.1 and Node 22, so the build environment has to be upgraded too.

Flutter or native apps. This means rewriting the UI, and C# or JavaScript code won’t carry over directly. The decision makes sense when the current technology limits the product, nobody wants to keep maintaining it, or you are planning a rebuild anyway. Two of our articles can help: the comparison of Flutter, React Native and Kotlin Multiplatform and how to decide between refactoring and rewriting based on numbers.

The choice usually comes down to three questions. Who will maintain the app in two years, and what language do they work in? How much code can you actually keep? Is the current technology getting in the way of users, or only of developers?

What has to survive the migration

Users shouldn’t notice the technology change. These are the things that break most often:

• App identifier and signature. The same applicationId and bundle ID, plus the right signing key, are what make the new version an update. Without them you get a new app with no users, ratings or history. We explain how to sort out keys and accounts in our article on transferring an app to another account.
• Data on the device. SQLite databases, login tokens and settings have to be readable after the update. In WebView apps even the URL scheme matters: when an Ionic app moves from Cordova to Capacitor, iOS defaults to a different one, which can wipe LocalStorage data, so the guide recommends setting server.iosScheme to ionic.
• Notifications and links. Check push token registration, opening the app from a notification, Universal Links and App Links.
• Payments and subscriptions. Product identifiers stay the same, but the new library has to recognise purchases that are already active, including on restore.
• Permissions. Capacitor sets its own defaults, so anything plugins used to add has to be moved by hand.

The first release after the migration should look and work like the previous one. New features can wait. Roll it out gradually with staged rollout on Google Play and phased release on the App Store, watching for crashes before the version reaches everyone.

How long it takes

The effort depends mainly on the number of plugins, the amount of custom native code and the state of the project, and only then on the number of screens. As a rough guide:

These are ranges, not a quote. A more accurate figure is possible after reviewing the project, its dependencies and its release process.

Where to start

1. Secure your access. The repository, store accounts, signing keys and external services. The checklist for taking over a project from another vendor will help.
2. Build the current version. Even if it takes an old operating system and old tools, you need a reference point. It is also the fastest way to find out whether your source code is complete.
3. Check the warnings in Play Console and Apple’s current requirements. They show how close the block is.
4. List your plugins and libraries. Mark each one: keep, replace or remove. This list drives most of the migration cost.
5. List the key flows. Login, payments, notifications, the most important screens. You will test the new version against this list, even if the project has no automated tests.
6. Only then choose a direction. A decision made without this knowledge often ends in either an unnecessary rewrite or a migration that stalls at the first plugin.

The sooner you do this, the more options you have. Without the pressure of an urgent fix, you can compare routes calmly and release the new version in stages.

We work in Kotlin, Swift and Flutter, and we help owners of older apps regain the ability to release them — through app reactivation or a mobile app takeover from the previous vendor. If you don’t know how urgent the migration is in your case, order a free app analysis — you will get the results in writing.