Microsoft puso fin al soporte de Xamarin y Xamarin.Forms el 1 de mayo de 2024. El camino con soporte hacia adelante es .NET MAUI (Multi-platform App UI), que es, a grandes rasgos, el sucesor arquitectónico de Xamarin.Forms con un tiempo de ejecución .NET unificado y una única estructura de proyecto. El discurso de marketing es "migración fácil". La realidad es más matizada. Tras varias migraciones reales, esta es la guía que usamos.
Qué significa realmente “migrar”
La primera decisión es definir el alcance con honestidad. Hay tres proyectos posibles sobre una base de código existente de Xamarin.Forms, y desde fuera se ven casi idénticos:
- Migración mecánica. Convertir los archivos del proyecto, cambiar los espacios de nombres, actualizar la sintaxis de los enlaces y publicar. En el mejor de los casos: de 2 a 4 semanas para una app de tamaño medio.
- Migración con limpieza. Lo mismo que lo anterior, más retirar las partes que ya sabías que estaban flojas (renderizadores personalizados que ahora deberían ser handlers de MAUI, navegación a medida que ahora debería usar Shell, código asíncrono que viene crujiendo). De 6 a 10 semanas.
- Migración como reescritura. La base de código ha acumulado más de 5 años de parches, el arquitecto original se fue y la estrategia de pruebas es "lo revisamos a mano antes de cada versión". MAUI es tu excusa para entregar una base de código sostenible. De 12 a 24 semanas.
El error que vemos con más frecuencia es suponer que el proyecto es del primer tipo cuando en realidad es del tercero. Los sprints de descubrimiento existen por algo.
Qué se traslada sin problemas
- Páginas XAML con controles estándar. Si tus vistas son en su mayoría Label, Button, Entry, ListView, etc., el XAML se actualiza sin problemas. Algunos nombres de propiedades cambiaron en ciertos lugares (la jerarquía FormattedText → FormattedString es la misma; algunas rutas de propiedades adjuntas se movieron). El .NET Upgrade Assistant detecta la mayoría de estos casos.
- ViewModels y servicios. C# puro: tu lógica de negocio, los enlaces MVVM y el registro de DI por lo general pasan sin cambios.
- Llamadas a HttpClient y serialización JSON. Sin cambios. (Si sigues con Newtonsoft.Json, este es un buen momento para considerar System.Text.Json, pero ese es un proyecto aparte.)
Qué no se traslada sin problemas
- Renderizadores personalizados. El modelo de renderizadores de Xamarin fue reemplazado por los handlers de MAUI. El concepto es similar, pero la superficie de la API es distinta y el ciclo de vida es distinto. Planea reescribir cada renderizador en lugar de esperar un cambio de una sola línea.
- Effects. La misma historia: por lo general se reconstruyen como personalización de handlers específica por plataforma.
- Controles de UI de terceros. Que se trasladen o no depende del proveedor. Telerik y Syncfusion lanzaron versiones para MAUI; los proveedores más pequeños a menudo no lo hicieron. Inventaría tus dependencias por adelantado.
- Configuración de notificaciones push. La configuración nativa de iOS/Android ha cambiado (sobre todo con los cambios del SDK de Firebase para iOS). No des por hecho que tu código de push existente "simplemente funciona".
- Pantallas de inicio e iconos de la app. MAUI tiene un modelo de recursos unificado (MauiSplashScreen, MauiIcon), mucho mejor, pero es una conversión puntual que toma a los equipos por sorpresa.
Decisiones de arquitectura que conviene tomar pronto
Shell vs. NavigationPage
Si tu app de Xamarin usa NavigationPage en todas partes, puedes mantener ese patrón en MAUI, pero Shell es el valor predeterminado recomendado para apps nuevas y te da mucho gratis (enrutamiento basado en URL, flyout, búsqueda). Para la mayoría de las apps que hemos migrado, la decisión correcta es "quédate con NavigationPage para la v1 y planea el cambio a Shell para la v2". Mezclarlos es desordenado.
Proyecto único vs. proyectos cabecera
La estructura de proyecto único de MAUI (un solo .csproj para iOS+Android+Windows+macOS) es el nuevo valor predeterminado. Xamarin usaba proyectos cabecera separados por plataforma. La conversión es en su mayoría mecánica, pero si tienes código específico de plataforma que vivía en los proyectos cabecera, tendrás que reubicarlo en las carpetas Platforms/. Los equipos subestiman esto cuando tienen mucha personalización nativa de AppDelegate o MainActivity.
Versión mínima de iOS
La versión mínima de iOS en MAUI varía según la versión de .NET y el tipo de app, así que consulta la matriz actual de plataformas con soporte de Microsoft antes de comprometerte (las versiones recientes de .NET MAUI / MAUI Blazor han subido los mínimos a iOS 12.2 e iOS 16.4 respectivamente, y ese piso sigue subiendo). Si tu app de Xamarin daba soporte a versiones de iOS más antiguas porque alguna base de clientes lo necesitaba, tendrás una conversación real sobre recortar ese soporte durante la migración.
Rendimiento y arranque
El arranque de MAUI suele ser más rápido que el de Xamarin.Forms, especialmente en iOS. Pero hay una ganancia real por conseguir con una compilación AOT adecuada en iOS y las nuevas opciones $(MtouchInterpreter). No aceptes el valor predeterminado; perfila y ajusta. Hemos visto mejoras de arranque del 30% al 50% solo con el ajuste de banderas de compilación que nadie se molestó en tocar.
Pruebas durante la migración
Si tu app de Xamarin tiene pruebas automatizadas escasas o nulas, ese es el problema mayor que vas a sacar a la luz. MAUI no tiene una estrategia de pruebas drásticamente mejor que la de Xamarin. Nosotros usamos:
- xUnit/NUnit para pruebas de ViewModel y de servicios (estas se trasladan sin cambios)
- Appium o las pruebas de UI con Hot Reload de la versión preliminar de MAUI para extremo a extremo
- QA manual en una matriz de dispositivos reales durante el corte de la migración. La regla práctica de Calvin: al menos un dispositivo por cada versión mayor de sistema operativo con soporte
Estrategia de corte
Para apps de consumo publicarás una única compilación de MAUI que reemplace la de Xamarin en las tiendas. Para apps empresariales/B2B con una flota de dispositivos conocida (apps para representantes de ventas, herramientas de almacén), hemos hecho despliegues en paralelo por TestFlight / canal interno: mantienes instalada la app de Xamarin mientras un pequeño grupo piloto ejercita la versión de MAUI. ¿Encontraste un error? Lo parchas en MAUI sin afectar a los usuarios en producción que siguen en la compilación estable de Xamarin.
El costo oculto: las dependencias de terceros
Lo que rompe los presupuestos es la larga lista de bibliotecas de terceros que olvidaste que usabas. Xamarin tuvo más de 10 años de ecosistema de plugins; no todo tiene sucesores compatibles con MAUI. Antes de firmar una migración a precio cerrado, audita cada referencia de NuGet. Cualquier cosa que no se haya actualizado desde 2022 es una señal de alerta.
La conclusión
Para la mayoría de las apps la migración es trabajo de verdad, no una refactorización de una semana: algo entre un traslado y una reescritura parcial. La buena noticia: una vez que estás en MAUI, estás en una plataforma con soporte, en desarrollo activo y con futuro. La mala noticia: ya nadie está produciendo trabajo nuevo en Xamarin, así que aunque tu app esté "bien", la cantera de talento para mantenerla se reduce cada trimestre.
Si tienes una app de Xamarin que intentas dimensionar para una migración, escríbenos. Haremos una auditoría real antes de cotizar: así es como evitamos la trampa de la “migración mecánica que se convirtió en reescritura”.