Si en 2026 sigues ejecutando una app de Xamarin, esta es la situación en términos claros. Microsoft terminó el soporte de todos los SDK de Xamarin el 1 de mayo de 2024. Tu app sigue funcionando y sigue en las tiendas, pero no recibe correcciones, ni parches de seguridad, ni asistencia técnica — y sus SDK finales se quedan en Android API 34 y Xcode 15 (iOS 17), sin nuevas APIs de plataforma por venir. La fecha de fin de soporte no es el verdadero límite. El verdadero límite es el día en que Apple o Google dejen de aceptar nuevos envíos construidos con esos SDK, porque ese es el día en que ya no podrás publicar una actualización. Tienes cuatro opciones realistas: migrar Xamarin.Forms a .NET MAUI, pasar los proyectos nativos a .NET para Android/iOS, reescribir en Flutter o ejecutar un congelado controlado mientras planificas. Así se decide.
Qué cambió realmente el “fin de soporte”
El fin de soporte no significa que tu app se apagara. Significa tres cosas concretas:
- No más correcciones ni actualizaciones. Los errores del runtime de Xamarin, incluidos los de seguridad, no se parchearán.
- No hay nuevas APIs de plataforma. Los SDK finales de Xamarin llegan hasta Android API 34 y Xcode 15. Las capacidades más nuevas del sistema operativo simplemente no son alcanzables.
- No hay asistencia técnica oficial. A partir de aquí dependes del soporte de la comunidad y de tu propio equipo.
Nada de eso retira tu app de las tiendas hoy. Pone en marcha un reloj de combustión lenta, y ese reloj lo controlan las tiendas — no Microsoft.
La única fecha límite que importa: los requisitos de SDK de las tiendas
Tanto Apple como Google suben periódicamente el nivel mínimo de SDK y de target API necesario para enviar una app. Google Play impone un requisito de target API que aumenta cada año; Apple exige builds hechas con un Xcode/SDK reciente.
Los SDK finales de Xamarin se quedan en Android API 34 y Xcode 15. Así que la lógica es directa: en algún momento, los mínimos de las tiendas superan lo que Xamarin puede producir, y tu siguiente actualización es rechazada. Tu app no desaparece — se congela. Ya no puedes corregir un fallo, responder a una divulgación de seguridad ni publicar una función. Para una app crítica de negocio, “ya no podemos publicar actualizaciones” es el momento en que el coste de esperar se vuelve ilimitado, y llega en el calendario de la tienda, no en el tuyo. Por eso la decisión es un problema de planificación ahora, no un problema de apagar incendios más tarde.
Opción 1 — Migrar Xamarin.Forms a .NET MAUI
Si tu app es una app típica de Xamarin.Forms y tu equipo está invertido en C# y .NET, este suele ser el camino más corto. La guía de Microsoft es explícita: los proyectos deben pasar a formato SDK-style, pero no hace falta reescribirlos. La lógica de negocio, los view models y los servicios se trasladan en gran medida intactos. El esfuerzo se concentra en la capa de UI — en concreto en los custom renderers, que .NET MAUI sustituye por handlers — más las dependencias de terceros y el código específico de plataforma.
Elige esto si: quieres seguir en .NET, tu app es Xamarin.Forms y valoras conservar tu código actual. Desglosamos lo que cuesta en la guía de coste y esfuerzo de la migración de Xamarin a .NET MAUI.
Opción 2 — Migrar los proyectos nativos a .NET para Android / .NET para iOS
Si tu app es Xamarin.Android o Xamarin.iOS nativa (no Forms), no adoptas MAUI en absoluto. Microsoft integró esos tipos de proyecto directamente en .NET: Xamarin.Android, Xamarin.iOS y Xamarin.Mac ahora son .NET para Android, .NET para iOS y .NET para Mac. Actualizas los proyectos a formato SDK-style y los reorientas sobre .NET moderno.
Elige esto si: construiste nativo en lugar de Forms y quieres volver a un .NET con soporte sin adoptar un nuevo framework de UI.
Opción 3 — Reescribir en Flutter
Algunos equipos aprovechan el movimiento forzado como el momento de replantearse el stack por completo. Flutter es un destino creíble cuando quieres un único toolkit de UI para móvil y web, cuando tu equipo se aleja de .NET, o cuando la app de Xamarin es lo bastante antigua como para que una reconstrucción limpia salga más barata que desenredarla.
Sé honesto sobre lo que es esto: una reescritura, no una migración. Tu lógica de negocio en C# no viaja contigo, y el coste es mayor que en las Opciones 1 o 2. Elige Flutter por razones estratégicas — dirección de plataforma, contratación, un comienzo genuinamente nuevo — no como atajo para evitar una migración a MAUI. Comparamos ambas directamente en nuestra próxima pieza de Flutter vs .NET MAUI; por ahora, trátalo como la opción de “cambiar de dirección”, no como la opción por defecto.
Opción 4 — Congelado controlado (ganar tiempo, de forma deliberada)
No hacer nada es una elección, y en ocasiones la correcta — pero solo como un congelado controlado, no como abandono. Eso significa: has medido cuánto margen te queda en las tiendas, tienes un plan de monitorización de seguridad para el runtime sin parches y tienes una fecha financiada para empezar el movimiento real. Un congelado controlado es una decisión de planificación con fecha de fin. Un congelado no controlado es un riesgo que no has puesto en precio.
Elige esto solo si: la app es genuinamente de bajo riesgo o de vida corta, y tienes por escrito cuándo termina el congelado.
Si has perdido al equipo original
Muchas apps de Xamarin han sobrevivido a los ingenieros que las construyeron. Si nadie puede explicar por qué la app se comporta como lo hace, todas las opciones anteriores se vuelven más arriesgadas, porque una migración “fiel” puede arrastrar fielmente errores o descartar en silencio comportamiento no documentado del que un usuario depende.
Antes de migrar o reescribir, recupera el modelo de producto a partir del código. Explicamos el método en recuperar el conocimiento de producto de un repositorio legacy y en la checklist de discovery de repositorios legacy. Este “Paso 0” es lo que evita que una migración se convierta en un caro proyecto de arqueología a mitad de camino.
Cómo elegir
Una guía rápida de decisión:
| Tu situación | Opción más probable |
|---|---|
| App de Xamarin.Forms, sigues en .NET | .NET MAUI (Opción 1) |
| App nativa de Xamarin, sigues en .NET | .NET para Android/iOS (Opción 2) |
| Replanteando el stack; quieres móvil + web desde un toolkit | Reescritura en Flutter (Opción 3) |
| App de bajo riesgo o vida corta, con fecha de fin por escrito | Congelado controlado (Opción 4) |
| Cualquiera de las anteriores, pero el equipo original ya no está | Haz discovery del legacy primero, luego decide |
El movimiento equivocado es dejar que el reloj de la tienda decida por ti. Una vez que una actualización es rechazada, decides bajo presión y sin margen — la forma más cara de migrar.
Dónde encaja MaboaSoft
La modernización de Xamarin y la migración de Xamarin a MAUI son parte central de lo que hacemos, y trabajamos como un equipo senior integrado, no como una fábrica de horas. Si quieres ayuda para decidir entre estas opciones — o un plan dimensionado y una estimación una vez decidido — reserva una llamada de 20 minutos, lee la guía de coste y esfuerzo de la migración o mira cómo trabajamos.
FAQ
¿Cuándo terminó el soporte de Xamarin? Microsoft terminó el soporte de todos los SDK de Xamarin — incluidos Xamarin.Forms, Xamarin.Android y Xamarin.iOS — el 1 de mayo de 2024. A partir de esa fecha no hay correcciones, parches de seguridad ni asistencia técnica, y los SDK finales solo llegan hasta Android API 34 y Xcode 15 (iOS 17).
¿Puedo seguir publicando mi app de Xamarin en 2026? Por ahora, sí: una app de Xamarin existente sigue funcionando y permanece en las tiendas. La limitación es que sus SDK finales se quedan en Android API 34 y Xcode 15. A medida que Apple y Google suben los niveles mínimos de SDK y target API que aceptan para nuevos envíos, una app que no pueda pasar de esos niveles acabará sin poder publicar actualizaciones. Ese requisito de las tiendas, y no la fecha de fin de soporte en sí, es el límite que fuerza la decisión.
¿Qué opciones tengo si sigo en Xamarin? Hay cuatro caminos realistas. Migrar Xamarin.Forms a .NET MAUI. Migrar apps nativas de Xamarin a .NET para Android y .NET para iOS. Reescribir en otro framework como Flutter. O ejecutar un congelado controlado mientras planificas. La elección correcta depende de cuánta UI personalizada tengas, de si quieres seguir en el ecosistema .NET y de cuánto margen te dé tu situación en las tiendas.
¿Debería migrar a .NET MAUI o reescribir en Flutter? Si tu equipo está invertido en C# y .NET y tu app es una app de negocio típica de Xamarin.Forms, .NET MAUI es el camino más corto porque la lógica de negocio, los view models y los servicios se trasladan sin reescritura. Flutter tiene más sentido cuando ya estás replanteándote el stack, quieres un único toolkit de UI para móvil y web, o tu equipo se aleja de .NET. Es una reescritura, así que el coste es mayor: elígelo por razones estratégicas, no para escapar de la migración.
Fuentes (consultadas el 14 de julio de 2026):
- Microsoft, política de soporte de Xamarin — fin de soporte el 1 de mayo de 2024; SDK finales en Android API 34 y Xcode 15; los tipos de proyecto nativos de Xamarin pasan a ser .NET para Android / iOS / Mac.
- Microsoft Learn, Upgrade from Xamarin to .NET — proyectos SDK-style, sin reescritura, Xamarin.Forms a .NET MAUI.
- Google Play, requisitos de target API; Apple, requisitos de envío a la App Store — mínimos de las tiendas que aumentan con el tiempo.