Running Unsupported Xamarin or PhoneGap in Production? Here's What's Actually at Risk
Xamarin reached end of life in May 2024. PhoneGap was discontinued in 2020. If your production mobile apps still run on either framework, you are accumulating risk that compounds with every OS release cycle.
- No security patches means known vulnerabilities go unaddressed indefinitely.
- Apple’s Xcode SDK requirements will eventually block App Store submissions for Xamarin-built apps.
- Plugin ecosystems for both frameworks are largely abandoned, so new device features are unreachable.
- The risk is not theoretical. It is measurable and increasing on a quarterly cadence.
- Migration paths exist for both frameworks, and AI-assisted tooling has reduced migration timelines significantly.
The framework is dead. The app is not. That is the problem.
Your Xamarin or PhoneGap app probably still works. Users can open it, data flows, the screens load. Nothing has visibly broken. This is precisely why unsupported mobile frameworks are so dangerous: the risk is invisible until it is not.
Unlike server-side software, mobile apps operate in an environment controlled entirely by Apple and Google. When iOS 19 ships in September 2026, every app on the App Store must comply with Apple’s updated SDK requirements. When Android 16 changes its permission model, every app on Google Play must adapt. Your framework vendor was responsible for making those adaptations. Your framework vendor is no longer doing that.
This is not a hypothetical risk. It is a timeline.
What “unsupported” actually means in practice
End-of-life for a mobile framework has four concrete consequences:
No security patches. When a vulnerability is discovered in Xamarin’s iOS bindings or PhoneGap’s WebView bridge, there is no patch coming. Your app is exposed, and the exposure is permanent. For applications handling personal data, financial transactions, or health information, this is a compliance issue, not just a security one.
No OS compatibility updates. Apple and Google release major OS versions annually and minor updates quarterly. Each release can change APIs, deprecate behaviours, or tighten security restrictions. A supported framework tracks these changes and ships updates. An unsupported framework does not. Your app may work on iOS 18 today but break on iOS 19 in September.
No build tooling updates. Xcode and Android Studio update their build chains regularly. Xamarin’s MSBuild integration and PhoneGap’s CLI depend on specific versions of these tools. As the build tools advance, the unsupported framework falls behind. Eventually, you cannot build a new version of your app at all, even to fix a critical bug.
No plugin ecosystem. Both Xamarin and PhoneGap relied heavily on community plugins for device features (camera, biometrics, push notifications, NFC). Plugin authors have moved on to MAUI, React Native, or Flutter. Existing plugins receive no updates. New device capabilities (Apple’s latest AR APIs, Android’s predictive back gesture) are permanently out of reach.
The App Store rejection timeline
Apple’s annual Xcode SDK requirements are the most concrete risk. Each year, Apple raises the minimum SDK version required for new app submissions and, eventually, for updates to existing apps.
Xamarin’s last supported Xcode version is fixed. It cannot target newer Xcode SDKs because Microsoft is no longer shipping Xamarin updates. The timeline looks like this:
- New app submissions will fail first, as Apple’s minimum SDK requirement for new apps advances past Xamarin’s last supported version.
- Updates to existing apps will fail next, typically 12-18 months after new submissions are blocked.
- Existing apps already on the store continue to work for users who have installed them, but you cannot ship bug fixes, security patches, or feature updates.
Google Play has similar requirements, though historically with longer grace periods.
The practical consequence: you will eventually be unable to ship any update to your production app, including critical security fixes.
The compliance dimension
For UK enterprises operating under GDPR, the Data Protection Act 2018, or sector-specific regulations (FCA for financial services, CQC for healthcare), running production apps on unsupported frameworks creates specific compliance exposure.
Article 32 of GDPR requires “appropriate technical and organisational measures” to protect personal data. Running an application on a framework with known, unpatched vulnerabilities is difficult to defend as “appropriate” in a regulatory investigation.
Cyber Essentials and Cyber Essentials Plus (required for many UK government contracts) mandate that software is “supported” and receiving security updates. An unsupported mobile framework directly conflicts with this requirement.
PCI DSS (for applications handling payment data) requires that all system components are protected from known vulnerabilities. Unsupported framework components cannot meet this requirement.
The risk is not that your app will be breached tomorrow. The risk is that when an incident occurs, your inability to patch the framework becomes evidence of negligence.
Quantifying the operational risk
Beyond compliance, unsupported frameworks create operational risks that compound over time:
Developer availability. Xamarin and PhoneGap developers are migrating their skills to MAUI, React Native, and Flutter. Finding developers willing to work on a deprecated framework is increasingly difficult and expensive. When your current Xamarin developer leaves, replacing them takes longer and costs more than it did a year ago.
Bug fix velocity. Without framework-level support, every bug that touches the framework layer becomes your team’s responsibility to work around. What was previously a one-line framework update becomes a multi-day investigation and custom patch.
Feature stagnation. New business requirements that depend on modern device capabilities (biometric authentication, AR, offline-first sync, push notification channels) may be impossible to implement on the unsupported framework.
What to do about it
The migration paths are well-understood. The question is not whether to migrate, but which target and when.
Xamarin.Forms to .NET MAUI: The lowest-friction path for Xamarin.Forms apps. Same language (C#), shared patterns, and Microsoft provides migration tooling. The biggest breaking change is Custom Renderers to Handlers. See our Xamarin to .NET MAUI migration guide for a detailed walkthrough.
Xamarin or PhoneGap to React Native: The right move when you want a broader ecosystem, JavaScript/TypeScript expertise, or when the app needs significant UI redesign anyway. See our guide on migrating from Xamarin or PhoneGap to React Native.
For the decision between MAUI and React Native: See our honest comparison for enterprise teams.
AI-assisted development has compressed mobile migration timelines. Claude Code can handle much of the mechanical translation (component conversion, API mapping, test migration), freeing developers to focus on the architectural decisions and device-specific testing that require human judgement. For context on how we use AI tooling in migration work, see our mobile migration playbook.
What we have seen in practice
[CLIENT EXAMPLE: Insurance company with a Xamarin.Forms claims submission app, 45k LOC. App was rejected from the App Store during a routine update submission due to outdated Xcode SDK. The rejection forced an emergency migration to .NET MAUI over 6 weeks. Had the migration been planned rather than reactive, it would have taken 4 weeks and cost 30% less. The emergency timeline compressed testing and required a follow-up stabilisation sprint.]
[CLIENT EXAMPLE: Field services company with a PhoneGap app for job scheduling and photo capture, ~20k LOC. Cordova plugins for camera access and offline storage stopped working after an Android 14 update. The app was migrated to React Native over 5 weeks, with AI-assisted translation handling approximately 55% of the component conversion. The rebuild also enabled push notification improvements that had been requested for two years but were impossible on PhoneGap.]
The cost of waiting
Every quarter you delay migration, the cost increases. Build tooling drifts further from current versions. Developers become harder to find. The gap between your framework’s last supported OS version and the current OS version widens. And if Apple or Google forces the issue with an App Store rejection, you lose the ability to choose your own timeline.
If your production apps run on Xamarin or PhoneGap, the question is not whether to migrate. It is whether you do it on your terms or on Apple’s.
For a structured assessment of your mobile estate and a migration plan tailored to your situation, book a free Mobile Migration Assessment.
For a broader view of the IP and licensing considerations when using AI tools for migration, see Who Owns AI-Written Code?. For general guidance on choosing between modernisation and replacement, see our Modernise, Rebuild, or Replace framework.