.NET MAUI en 2026: apps nativas multiplataforma con C# y una base de código

.NET MAUI (Multi-platform App UI) es el framework de Microsoft para crear apps nativas para Android, iOS, macOS y Windows usando C# y un único proyecto. Llegó con .NET 6 en 2022 como el reemplazo directo de Xamarin.Forms, que quedó oficialmente depreciado en mayo de 2024.

Si tienes proyectos en Xamarin.Forms, la migración a MAUI no es opcional: Microsoft ya no publica actualizaciones de seguridad para Xamarin. La buena noticia es que la mayor parte del código XAML y de los ViewModels se migra sin cambios estructurales grandes, aunque sí hay que adaptar el proyecto y algunas APIs.

La diferencia más visible con Xamarin.Forms es la arquitectura Single Project. Antes tenías un proyecto por plataforma (Android, iOS, UWP) más el proyecto compartido. Con MAUI hay un solo .csproj que se compila para los cuatro targets. Eso simplifica mucho la gestión de NuGet, los assets y el control de versiones.

Arquitectura Single Project: cómo está organizado un proyecto MAUI

Cuando creas un proyecto nuevo con dotnet new maui o desde Visual Studio, la estructura que obtienes es esta:

MiApp/
??? Platforms/
?   ??? Android/
?   ??? iOS/
?   ??? MacCatalyst/
?   ??? Windows/
??? Resources/
?   ??? Images/
?   ??? Fonts/
?   ??? Splash/
??? MainPage.xaml
??? MainPage.xaml.cs
??? App.xaml
??? MauiProgram.cs
??? MiApp.csproj

El código en la raíz del proyecto es código compartido que se compila para todas las plataformas. Las carpetas dentro de Platforms/ contienen código específico de cada sistema: puedes poner ahí cualquier cosa que solo tenga sentido en Android o en iOS sin que afecte al resto de builds.

Para casos puntuales donde necesitas comportamiento diferente dentro del código compartido, MAUI tiene directivas de compilación condicional:

#if ANDROID
    // Solo en Android
#elif IOS
    // Solo en iOS
#endif

Úsalas con moderación. Si te encuentras llenando el código compartido de #if, suele ser señal de que ese código debería estar en las carpetas Platforms/.

XAML y C# para la UI

MAUI usa XAML para definir la interfaz, el mismo lenguaje que WPF y WinUI. Si has trabajado con alguno de los dos, la sintaxis te resulta familiar. Un componente básico en XAML:

<Label Text="Hola" FontSize="18" HorizontalOptions="Center" />

El data binding funciona con la misma sintaxis que en WPF:

<Label Text="{Binding NombreUsuario}" />
<Entry Text="{Binding Email, Mode=TwoWay}" />

Cada archivo .xaml tiene su .xaml.cs de code-behind para el manejo de eventos. Para lógica de UI sencilla está bien, pero en proyectos medianos o grandes lo recomendable es mover esa lógica a un ViewModel.

Si prefieres no usar XAML, MAUI también permite definir la interfaz enteramente en C# con el Fluent API. El resultado es equivalente, pero la mayoría de la comunidad y los ejemplos oficiales usan XAML.

MVVM: el patrón que manda en MAUI

Model-View-ViewModel es el patrón de referencia en MAUI. La vista (el XAML) se conecta mediante bindings a un ViewModel que expone propiedades y comandos. El ViewModel no sabe nada de la vista, lo que facilita las pruebas unitarias.

El ViewModel implementa INotifyPropertyChanged para notificar a la vista cuando cambia el estado:

public class MainViewModel : INotifyPropertyChanged
{
    private string _nombre;
    public string Nombre
    {
        get => _nombre;
        set
        {
            _nombre = value;
            OnPropertyChanged();
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged([CallerMemberName] string prop = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(prop));
}

Escribir esto a mano para cada propiedad es tedioso. Por eso existe CommunityToolkit.Mvvm, la librería de Microsoft que usa source generators para generar ese código automáticamente. Con el toolkit, el ViewModel anterior queda así:

[ObservableObject]
public partial class MainViewModel
{
    [ObservableProperty]
    private string _nombre;
}

El generator crea la propiedad pública Nombre con su INotifyPropertyChanged completo. También tienes [RelayCommand] para generar comandos a partir de métodos normales. En proyectos nuevos, usar el toolkit desde el principio ahorra mucho trabajo.

Shell: navegación y estructura de la app

Shell es el contenedor principal de una app MAUI y define tanto la estructura de navegación como el aspecto visual del chrome (barra superior, menú lateral, tabs). En el AppShell.xaml declaras las páginas de tu app:

<Shell>
    <TabBar>
        <Tab Title="Inicio" Icon="home.png">
            <ShellContent ContentTemplate="{DataTemplate local:HomePage}" />
        </Tab>
        <Tab Title="Perfil" Icon="profile.png">
            <ShellContent ContentTemplate="{DataTemplate local:ProfilePage}" />
        </Tab>
    </TabBar>
</Shell>

Para navegar entre páginas desde código, usas rutas. Primero las registras en MauiProgram.cs o en el AppShell.xaml.cs:

Routing.RegisterRoute("DetalleProducto", typeof(DetalleProductoPage));

Y luego navegas pasando parámetros por query string:

await Shell.Current.GoToAsync($"DetalleProducto?Id={producto.Id}");

En la página de destino, recibes el parámetro con el atributo [QueryProperty]. Es un sistema cómodo y que escala bien para apps con bastantes pantallas.

Acceso a funcionalidades nativas

MAUI incluye un conjunto de APIs multiplataforma para las funcionalidades más habituales. Algunas de las más usadas:

• Geolocalización: await Geolocation.GetLocationAsync()
• Cámara y galería: await MediaPicker.PickPhotoAsync() / await MediaPicker.CapturePhotoAsync()
• Preferencias: Preferences.Set("clave", "valor") y Preferences.Get("clave", "default")
• Almacenamiento seguro: await SecureStorage.SetAsync("token", valor) — usa Keychain en iOS y Keystore en Android
• Conectividad: Connectivity.NetworkAccess para saber si hay red disponible

Para APIs que MAUI no cubre directamente, vas a las carpetas Platforms/ y escribes el código nativo. Puedes usar interfaces para que el código compartido llame a implementaciones específicas de cada plataforma sin saber qué hay debajo.

Rendimiento en 2026: MAUI, Flutter y React Native

Una pregunta frecuente al evaluar MAUI es cómo se compara con Flutter o React Native. La respuesta honesta es que depende de qué priorizas.

MAUI genera controles nativos de cada plataforma: en Android usa views de Android, en iOS usa UIKit. El rendimiento visual es nativo porque literalmente está usando los componentes del sistema operativo. El handicap histórico de MAUI era la estabilidad de las versiones iniciales, algo que .NET 8 y .NET 9 han mejorado mucho.

Flutter tiene su propio motor de renderizado (Skia/Impeller) y dibuja todo en un canvas, sin usar los controles nativos de la plataforma. El rendimiento es muy bueno, pero la UI tiene un aspecto propio que no siempre encaja con las guías de cada plataforma. Dicho esto, Flutter ha ganado mucho terreno y su comunidad es muy activa.

React Native ha mejorado con la nueva arquitectura JSI, que elimina el bridge entre JavaScript y el código nativo, pero sigue siendo más complejo de depurar cuando aparecen problemas en el límite JS/nativo.

Si tu equipo ya trabaja con .NET y C#, MAUI es la opción con menos fricción: reutilizas conocimientos, herramientas (Visual Studio, Rider) y librerías NuGet. Para un equipo nuevo sin experiencia en .NET, Flutter puede tener una curva de aprendizaje más suave al principio.

.NET MAUI en 2026: el estado real del framework

Las versiones iniciales de MAUI (.NET 6 y .NET 7) tuvieron una recepción complicada. La comunidad reportó bastantes bugs en controles concretos, problemas de rendimiento en listas largas y lentitud en los tiempos de build. Eso generó cierto escepticismo que todavía se lee en foros y comentarios de Stack Overflow.

La situación con .NET 8 mejoró de forma notable. Microsoft priorizó la estabilidad sobre las nuevas funciones y el resultado se notó: las issues más votadas del repositorio se fueron cerrando y los tiempos de compilación bajaron. .NET 9 siguió esa línea con mejor soporte de gestos, mejoras en el manejo de controles nativos y un CollectionView más estable.

Para apps enterprise donde el equipo ya conoce C# y el stack .NET, MAUI es una opción sólida en 2026. Tienes integración directa con Azure, con las librerías de autenticación de Microsoft (MSAL), y con todo el tooling de Visual Studio incluyendo el depurador de UI. Para proyectos donde el equipo no tiene base en .NET, el cálculo cambia: Flutter o React Native pueden ser más adecuados dependiendo del contexto.

Lo que ya no tiene sentido es quedarse en Xamarin.Forms. El soporte terminó, las dependencias se quedan sin actualizar y el salto a MAUI, aunque requiere trabajo, es el camino que tiene continuidad.

Por dónde seguir

Si quieres profundizar en C# antes de meterte con MAUI, este artículo de programacion.net te pone en contexto: C# en el desarrollo móvil: de Xamarin a MAUI. Y si te interesa cómo encaja MAUI dentro del stack más amplio de Microsoft, aquí tienes más contexto: El ecosistema Microsoft en 2026: de la web al móvil.

Imagen: Pexels / panumas nikhomkhai