Cómo elegir entre WinForms, WPF y WinUI: tabla de decisión práctica

Público objetivo: desarrolladores que crean aplicaciones de escritorio para Windows con C#/.NET, y quienes deciden la selección tecnológica. Premisa: se asume el uso del .NET actual (no .NET Framework) y que la plataforma de destino es exclusivamente Windows. Cómo leer este artículo: si solo quiere la conclusión, lea los capítulos 1 y 3; si quiere decidir la política de continuidad de una aplicación existente, lea el capítulo 7; y si busca el argumento decisivo final, empiece por el capítulo 8.

Al crear aplicaciones de escritorio para Windows con C#/.NET, algo que resulta discretamente complicado cada vez es decidir cuál elegir entre WinForms, WPF y WinUI.

Lo peligroso aquí es:

• WinUI porque es lo más nuevo
• WinForms porque es lo que más se conoce
• WPF porque parece estar en un punto intermedio

Ese tipo de elección vaga es arriesgado.

En la práctica, los ejes que hay que observar son bastante más claros.

• ¿Es un desarrollo nuevo o la continuación de activos existentes?
• ¿Las pantallas se centran en formularios de entrada o se necesita expresividad?
• ¿Una UI moderna y típica de Windows es en sí misma parte del valor del producto?
• ¿Cómo se gestionarán la distribución, las actualizaciones y la operación dentro de la empresa?
• ¿El equipo tiene una cultura de Designer o una cultura de XAML/MVVM?

En este artículo organizamos todo esto de forma clara en una única tabla de decisión. Cabe aclarar que, en este artículo, WinUI se refiere principalmente a WinUI 3 + Windows App SDK.¹²

Además, estas tres tecnologías son todas exclusivas de Windows. Si también contempla macOS o Linux, el planteamiento del problema es directamente distinto.³⁴¹

1. Primero, la conclusión (en una frase)

Dicho de forma bastante simplificada pero útil para la práctica, sería así:

• Si su aplicación WinForms existente es grande, lo primero que hay que considerar como base es continuar con WinForms
• Si su aplicación WPF existente es grande, lo primero que hay que considerar como base es continuar con WPF
• Para una herramienta interna nueva de tamaño pequeño a mediano, centrada en controles estándar y pantallas de entrada, y que quiera crear rápidamente, WinForms sigue siendo bastante sólido³⁵
• Para una aplicación empresarial nueva de tamaño medio a grande, con muchas pantallas, en la que quiera aprovechar bien el enlace de datos, los estilos, las plantillas, los comandos y MVVM, WPF suele ser la opción más segura en la mayoría de los casos⁴⁶⁷
• Para un producto nuevo exclusivo de Windows en el que una UI moderna de Windows, Fluent y la experiencia más reciente de Windows estén directamente vinculados al valor del producto, WinUI es una opción sólida¹²
• Si solo quiere usar las API más recientes de Windows, WinUI no es obligatorio. WPF/WinForms también pueden incorporar funciones del Windows App SDK²⁸⁹¹⁰
• Elegir partiendo de la idea de que «más adelante podré ir incorporando WinUI poco a poco» es algo arriesgado. El tema de la migración gradual es más engorroso de lo que parece¹⁰¹¹

En resumen, se trata más o menos de esto:

1. Si los activos existentes son grandes, mantenga primero esa misma línea tecnológica
2. Para un desarrollo nuevo en el que quiera crear formularios estándar rápidamente, use WinForms
3. Para un desarrollo nuevo de una aplicación empresarial de Windows que crecerá a largo plazo, use WPF
4. Para un desarrollo nuevo en el que una UI moderna de Windows sea en sí misma un requisito, use WinUI
5. Si solo quiere usar el Windows App SDK, no pase todo directamente a WinUI

La selección del framework no es solo una decisión sobre tecnología de UI: también es una decisión sobre distribución, operación, costo de aprendizaje y costo de migración. Si esto se decide únicamente en función de «nuevo / antiguo», el efecto rebota más adelante sobre el diseño de la distribución y el costo de mantenimiento.

2. Las tres tecnologías de las que habla este artículo

Antes de nada, unifiquemos algo de terminología. Aquí desarrollamos las siglas que aparecerán constantemente a lo largo del artículo.

Microsoft Learn describe WinForms como un framework que incorpora controles, gráficos, enlace de datos y entrada de usuario, y que facilita crear aplicaciones con el Designer de arrastrar y soltar de Visual Studio.³

WPF es un framework de UI de alta expresividad que incluye renderizado vectorial independiente de la resolución, XAML, enlace de datos, estilos/plantillas, gráficos 2D/3D y animación.⁴

WinUI forma parte del Windows App SDK y es un framework de UI para el Windows actual, pensado desde el principio para alto DPI, entrada moderna, animaciones fluidas y experiencias del estilo Fluent.¹² Además, cuenta con un soporte normal para data binding y MVVM.¹²

Lo importante aquí es que el Windows App SDK y WinUI no son lo mismo. WinUI es la parte de framework de UI del Windows App SDK, pero el propio Windows App SDK puede añadirse también a aplicaciones existentes en WPF, WinForms o Win32.²¹⁰

Por eso,

• usar WinUI
• usar funciones del Windows App SDK

son decisiones que parecen similares pero en realidad son distintas. Si se discuten mezcladas, «si se migra la UI o no» y «si se añaden funciones o no» acaban tratándose como el mismo tema, y resulta difícil llegar a una conclusión.

3. Tabla de decisión de un vistazo

Primero, presentamos la tabla más útil para el uso práctico.

Con esta tabla suele bastar en la mayoría de los casos, pero quedan dos puntos que generan dudas con frecuencia.

1. En un desarrollo nuevo de una aplicación empresarial de Windows, ¿hacia WinForms o hacia WPF inclinarse?
2. Aun teniendo un WPF/WinForms existente, ¿conviene pasarse a WinUI?

Estos dos puntos resultan más fáciles de decidir observando la tabla comparativa que sigue a continuación.

4. Tabla comparativa por criterios

Esto no es una tabla oficial de superioridad, sino una comparación bastante orientada a la práctica.

La clave para leer esta tabla no es qué es lo más potente, sino qué genera menos fricción.

Por ejemplo,

• una herramienta interna de configuración
• una pantalla de configuración de equipos
• listados, detalles, búsquedas, ajustes, botones
• un caso en el que la estabilidad operativa y la velocidad de modificación importan más que la apariencia

en ese caso, WinForms sigue siendo bastante razonable.

Por el contrario,

• hay muchas pantallas
• hay muchos cambios de estado de visualización
• se quiere separar la View de la lógica
• se quiere conectar de forma natural los cambios de datos con la UI
• se quiere controlar la UI mediante estilos / plantillas

en ese caso, WPF funciona muy bien.⁶⁷

Y,

• se quiere partir de un aspecto propio de Windows 11
• se quiere aprovechar bien Fluent
• se quiere dar por sentado el alto DPI, la pantalla táctil y las API de ventana modernas
• es un producto nuevo, exclusivo de Windows, en el que la impresión de la UI también importa

en ese caso, WinUI resulta lo natural.¹²

4.1 La diferencia de expresividad, vista con el mínimo de código

La fila «Compatibilidad con enlace de datos / MVVM» de la tabla anterior es difícil de captar solo con palabras. A continuación mostramos, con el mínimo de código, qué cambia al escribir la misma pantalla en WinForms y en WPF.

Lo que construimos es una pantalla con un solo cuadro de texto y un solo botón de guardar.

WinForms: el Designer genera *.Designer.cs, y el valor se obtiene de la pantalla dentro del controlador de eventos.

// MainForm.Designer.cs — lado generado por el Designer. No es un lugar para escribir a mano
private System.Windows.Forms.TextBox nameTextBox;
private System.Windows.Forms.Button saveButton;

private void InitializeComponent()
{
    this.nameTextBox = new System.Windows.Forms.TextBox();
    this.saveButton = new System.Windows.Forms.Button();
    this.SuspendLayout();

    this.nameTextBox.Location = new System.Drawing.Point(12, 12);
    this.nameTextBox.Size = new System.Drawing.Size(200, 23);

    this.saveButton.Location = new System.Drawing.Point(218, 12);
    this.saveButton.Size = new System.Drawing.Size(75, 23);
    this.saveButton.Text = "Guardar";
    this.saveButton.Click += new System.EventHandler(this.SaveButton_Click);

    this.Controls.Add(this.nameTextBox);
    this.Controls.Add(this.saveButton);
    this.ResumeLayout(false);
}

// MainForm.cs — este es el lado que se escribe a mano
public partial class MainForm : Form
{
    private readonly EditorService _service;

    public MainForm(EditorService service)
    {
        _service = service;
        InitializeComponent();
    }

    private void SaveButton_Click(object sender, EventArgs e)
    {
        // Se obtiene el valor directamente del control de la pantalla y se pasa
        _service.Save(this.nameTextBox.Text);
    }
}

WPF: en el XAML solo se escribe «con qué se conecta»; el Binding se encarga de entregar y recuperar los valores.

<!-- MainWindow.xaml -->
<Window x:Class="MyApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Editar" Width="360" Height="120">
    <StackPanel Orientation="Horizontal" Margin="12">
        <TextBox Width="200"
                 Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
        <Button Width="75" Margin="6,0,0,0" Content="Guardar"
                Command="{Binding SaveCommand}" />
    </StackPanel>
</Window>

// MainWindow.xaml.cs — si olvida asignar el DataContext, el Binding no hará nada
public partial class MainWindow : Window
{
    public MainWindow(EditorService service)
    {
        InitializeComponent();
        this.DataContext = new MainViewModel(service);
    }
}

// MainViewModel.cs — el lado que no conoce la pantalla. Aquí también se pueden escribir pruebas unitarias
public sealed class MainViewModel : INotifyPropertyChanged
{
    private readonly EditorService _service;
    private string _name = string.Empty;

    public MainViewModel(EditorService service)
    {
        _service = service;
        SaveCommand = new RelayCommand(() => _service.Save(Name));
    }

    public string Name
    {
        get => _name;
        set
        {
            if (_name == value) return;
            _name = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name)));
        }
    }

    public ICommand SaveCommand { get; }

    public event PropertyChangedEventHandler PropertyChanged;
}

RelayCommand es una clase pequeña que implementa ICommand; está incluida en bibliotecas como CommunityToolkit.Mvvm, y también se puede crear una propia en unas 20 líneas.

Si solo se mira el número de líneas, WPF tiene más. La diferencia aparece a partir de aquí.

Con 3 pantallas, WinForms es más rápido; con 30, WPF resulta más liviano, ese es el significado práctico de esta diferencia.

5. Para qué tipo de proyecto es adecuado cada uno

5.1 WinForms

A WinForms se le suele menospreciar de forma injustificada, pero en un único punto —crear rápidamente pantallas empresariales centradas en controles estándar— sigue siendo digno de respeto hoy en día.³⁵

Es especialmente adecuado, por ejemplo, para proyectos como estos:

• Herramientas de configuración de uso interno
• Pantallas de configuración de equipos, instrumentos de medición o herramientas de monitorización
• Pantallas de administración, pantallas de búsqueda, listados con detalle
• Proyectos con activos WinForms existentes grandes
• Equipos con una cultura fuerte de componer pantallas con el Designer

La fortaleza de WinForms es que, sin necesidad de introducir filosofías complicadas, permite producir con bastante rapidez pantallas cercanas al resultado final. Formularios, botones, etiquetas, cuadros de texto, cuadrículas de datos. Si ese es el terreno principal, puede competir muy bien.

Sin embargo, también tiene puntos débiles claros.

• Se quiere unificar en gran medida el aspecto de toda la pantalla
• Se quiere controlar la UI mediante estilos y plantillas
• Se quiere gestionar cambios de estado complejos principalmente mediante enlace de datos
• Se quiere separar limpiamente la lógica de la pantalla

En estos aspectos, WPF o WinUI resultan más directos.

Al crear una aplicación grande con WinForms, si se baja la guardia, es fácil terminar con una selva de controladores de eventos. Por eso, si elige WinForms, conviene decidir de antemano al menos lo siguiente:

• Mantener pequeña la responsabilidad de cada pantalla
• Dividir por unidades de UserControl
• Tener en cuenta un límite equivalente a Presenter/ViewModel
• No escribir la lógica de negocio directamente pegada a los eventos de la pantalla

Además, algo bastante importante en la práctica es que no hace falta abandonar WinForms solo porque se quiera usar el Windows App SDK. De hecho, existe una vía oficial para añadir funciones del Windows App SDK a una aplicación WinForms existente.⁹¹⁰

Es decir, con WinForms se puede optar por

• mantener la UI tal cual
• modernizar solo las funciones de Windows necesarias

Este es un punto de acuerdo realista.

5.2 WPF

Visto como una UI .NET para el escritorio de Windows, WPF es el núcleo con mejor equilibrio.⁴

Sus fortalezas son claras.

• Se puede escribir la pantalla de forma declarativa con XAML
• El Data Binding es potente
• Se pueden usar Style/Template
• Se puede usar Command
• Facilita separar la View de la lógica
• Facilita organizar pantallas de tamaño medio a grande

La documentación oficial de WPF describe el enlace de datos como una función central de WPF, y presenta los comandos como un mecanismo para separar la entrada de la lógica de ejecución.⁶⁷

Por eso, es adecuado, por ejemplo, para proyectos como estos:

• Aplicaciones empresariales con muchas pantallas
• Muchos listados, detalles, ediciones, búsquedas y visualizaciones de estado
• Aplicaciones de Windows mantenidas a largo plazo por varias personas
• Se quiere separar la View de la lógica
• Se quiere mantener separadas de antemano las responsabilidades de apariencia y comportamiento, pensando en futuras modificaciones
• Casos en los que con WinForms las pantallas parecerían volverse pesadas rápidamente

Cuando se duda ante una aplicación empresarial nueva exclusiva de Windows, WPF sigue siendo hoy en día una primera opción segura. Descartarlo con un «WPF es antiguo, así que no» resulta un poco precipitado.

Al contrario, si

• ya tiene activos WPF existentes
• ya cuenta con conocimiento de XAML/MVVM
• Fluent no es su máxima prioridad
• pero quiere diseñar la UI de forma más limpia que con WinForms

es habitual que WPF sea, con diferencia, la opción más razonable.

Por supuesto, WPF también tiene sus particularidades.

• Si se complica demasiado el XAML, se vuelve difícil de leer
• Si se apilan demasiados controles y plantillas personalizados, el mantenimiento se vuelve pesado
• Si se inclina demasiado hacia la política de «resolverlo todo con Binding», resulta al contrario más difícil seguir el flujo del procesamiento

Estos aspectos existen ciertamente, pero más que un defecto de WPF, se trata de que una herramienta expresiva, si se usa con descuido, también genera una reacción mayor.

También en WPF se pueden añadir algunas funciones del Windows App SDK. Es decir, existe el camino de modernizar las funciones de Windows manteniendo WPF tal cual.⁸¹⁰

Por esto, en la práctica suele ganar más

• acercar WPF al .NET actual
• añadir solo las funciones de Windows necesarias mediante el Windows App SDK
• organizar la estructura empezando por las funciones nuevas de mayor tamaño

antes que

• abandonar WPF por completo y migrar totalmente a WinUI.

5.3 WinUI

WinUI es la opción moderna principal para crear una aplicación nueva exclusiva de Windows.¹²

Oficialmente se posiciona como

• optimizado para el hardware y la entrada más recientes
• alto DPI
• animaciones fluidas
• parte del Windows App SDK

¹

Por eso, es adecuado para proyectos como estos:

• Productos nuevos exclusivos de Windows
• La impresión de la UI y la experiencia en sí son importantes
• Se quiere usar Fluent de forma directa
• Se quiere alinear con el estado actual de Windows 11
• Se quiere dar por sentadas las API de ventana nuevas y la experiencia más reciente de Windows

Los proyectos que tienen un motivo sólido para elegir WinUI son, en general, aquellos en los que no se trata de «que se vea nuevo», sino de «querer incorporar al producto la experiencia actual de Windows».

Por otro lado, también hay puntos de atención.

5.3.1 WinUI no es «simplemente un WPF nuevo»

Como usa XAML, parece cercano, pero difiere en

• la API base
• lo relacionado con los controles
• la estructura del proyecto
• el planteamiento de implementación/empaquetado
• la forma de relacionarse con el Windows App SDK

Es decir, considerarlo un destino de reemplazo casual desde WPF es algo arriesgado.

5.3.2 Elegir WinUI hace que el tema de la distribución pase a primer plano

Una aplicación WinUI 3 tiene packaged como modo predeterminado. Por otro lado, el propio Windows App SDK admite tanto packaged como unpackaged.¹³¹⁴²

Lo importante aquí es decidir cuanto antes

• cómo se distribuirá
• cómo se instalará el runtime
• si se necesita package identity
• si será distribución interna, Store, MSIX, o la vía existente de EXE/MSI

Sin embargo, decir solamente «verifíquelo pronto» no aclara qué hay que mirar exactamente, así que a continuación detallamos el contenido de esa verificación.

Primero, hay dos ejes que decidir.¹³¹⁵

• packaging: si la aplicación tiene o no package identity
• runtime: si se usa el Windows App SDK como framework-dependent o se incluye como self-contained

Las opciones del lado de packaging son tres.¹³

A continuación, se determina si se necesita package identity desde el punto de vista de las funciones. Las funciones que la documentación oficial indica explícitamente que «no funcionan sin package identity» son, por ejemplo, estas:¹³

• Tareas en segundo plano
• Notificaciones push (WNS)
• Destino de uso compartido
• Extensión del menú contextual del Explorador
• Asociación de tipos de archivo y esquemas de URI
• Tareas de inicio
• App Service
• API de Windows AI

El orden práctico para verificar esto es el siguiente.

1. Parta de los requisitos. ¿Tiene previsto usar alguna función de la lista anterior? Si es al menos una, necesitará el lado packaged.
2. Compruebe si puede prescindir del instalador existente. Si no quiere prescindir de él, la respuesta no es una migración total a MSIX, sino un packaged que apunte a una ubicación externa. Puede mantener tal cual la disposición de binarios y el mecanismo de actualización existentes, y añadir solo el identity.¹³
3. Verifíquelo en tiempo de ejecución. Puede determinar si un proceso en ejecución tiene identity con GetCurrentPackageFullName. Si no tiene identity, se devuelve APPMODEL_ERROR_NO_PACKAGE. A la inversa, si al llamar a una API de Windows aparece E_ILLEGAL_METHOD_CALL o APPMODEL_ERROR_NO_PACKAGE, esa es la señal de que se ha topado con un requisito de package identity.¹³
4. Verifíquelo en el lado del equipo. Los paquetes instalados se pueden listar con Get-AppxPackage de PowerShell.
5. Por último, decida el runtime. Si quiere distribuir mediante xcopy o zip, la vía predeterminada es self-contained; si va a publicar en la Store, es framework-dependent.¹⁵

En WinForms/WPF la distribución también es importante, pero en WinUI este aspecto tiende a pasar a primer plano con más facilidad. Una aplicación WinUI 3 nueva es packaged de forma predeterminada, así que si no se decide nada, automáticamente se entra en la vía de MSIX.¹³ Lo un poco engorroso de este mundo es que, creyendo haber decidido solo la UI, en realidad ya se había decidido también la estrategia de distribución.

5.3.3 «Mezclar WinUI poco a poco en un WPF/WinForms existente»: experimente antes

Este es un punto donde las expectativas tienden a crecer con facilidad. Sin embargo, el FAQ de Microsoft también recoge, en esencia, que en muchos casos WinUI no se puede usar a menos que se esté preparado para migrar por completo el framework de UI. Además, en cuanto a XAML Islands, aunque la documentación oficial muestra una vía para incrustarlo en aplicaciones de escritorio existentes, las notas de la versión 1.4 del Windows App SDK indican que, por el momento, se ha probado principalmente su uso en aplicaciones C++, y que no se han incluido elementos envoltorio convenientes para WPF/WinForms.¹⁰¹¹

Es decir,

• «parece que se puede migrar por etapas»
• «parece que basta con ir incorporándolo poco a poco»

son ideas atractivas como concepto, pero conviene verificarlas a pequeña escala antes de convertirlas en la estrategia principal del proyecto.

WinUI resulta más razonable cuando

• se empieza desde cero
• se construye la experiencia como un producto exclusivo de Windows

Por el contrario, como receptor de un reemplazo total de un WPF/WinForms existente, hace falta un motivo y una verificación.

6. Errores de decisión habituales

6.1 «Es lo más nuevo, así que WinUI»

Esto es fácil de entender, pero bastante peligroso.

El motivo para elegir una tecnología nueva conviene evaluarlo desde si existe un valor que solo se obtiene con esa tecnología.

• ¿La experiencia moderna de Windows es parte del valor del producto?
• ¿Se quiere usar Fluent de forma directa?
• ¿Es un producto nuevo?
• ¿Se pueden aceptar las condiciones de distribución/operación?

Si la respuesta a esto es sí, WinUI es una opción sólida. Por el contrario, si el único argumento es que «parece tener futuro», la justificación del costo resulta débil.

6.2 «Quiero usar el Windows App SDK, así que tengo que pasarme a WinUI»

Esto se malinterpreta con facilidad, pero no es así.

El Windows App SDK también puede añadirse a un WPF/WinForms existente. El FAQ oficial también aclara que las aplicaciones WPF, MFC o WinForms pueden usar API del Windows App SDK que no tienen relación con WinUI.¹⁰⁸⁹

Por ejemplo,

• App Lifecycle
• Windowing
• Toast Notifications

funciones como estas a veces se pueden incorporar manteniendo la UI actual.¹⁰

6.3 «WPF/WinForms ya están acabados»

Aquí tampoco conviene descartarlos sin más.

Tanto WinForms como WPF mantienen documentación y vías de migración activas sobre el .NET actual, y Microsoft los sigue tratando oficialmente como UI de escritorio de Windows vigentes.³⁴

Como criterio para decidir sobre el mantenimiento a largo plazo, un indicador más claro que «si queda documentación» es si se siguen incorporando funciones nuevas. Vistas desde este ángulo, la situación de las tres tecnologías es la siguiente.

Es decir, desde el punto de vista del mantenimiento a largo plazo, se puede leer así:

• WPF y WinForms no están «congelados y abandonados»: reciben funciones con cada lanzamiento anual de .NET. Sin embargo, algunas de las funciones estrella de WinForms se encuentran en etapa experimental, por lo que hay que verificar el momento de adopción.
• Elegir WinUI implica gestionar por separado el plazo de soporte de .NET y el del Windows App SDK. En proyectos de largo plazo, esto pesa de forma discreta pero real.
• Sea cual sea la opción elegida, no hay garantía de que «funcione sin modificaciones dentro de 10 años», así que resulta más práctico decidir desde el principio hasta qué versión se dará seguimiento.

Especialmente en las aplicaciones empresariales,

• los activos existentes
• los controles de terceros
• el número de pantallas
• los informes y la impresión
• la integración con equipos
• los procedimientos de distribución

es habitual que estos aspectos pesen más que la novedad del framework de UI.

6.4 «Ya que estamos, reescribámoslo todo»

Una reescritura total se parece más a una decisión de negocio que a una selección tecnológica.

Si ya existe una aplicación, lo primero que hay que revisar es lo siguiente.

1. ¿Qué es lo que realmente causa problemas?
2. ¿Es un problema de UI o un problema de arquitectura?
3. ¿No es la verdadera carga las DLL dependientes, COM, OCX, los informes o la distribución?
4. ¿Se puede resolver el problema sin cambiar toda la UI?

Reescribir la UI es vistoso, pero el costo también lo es. Además, aunque el aspecto se renueve, la complejidad del entorno suele permanecer.

6.5 «Más adelante lo resolveremos con XAML Islands»

Esta expectativa es comprensible. Pero es más seguro no tratarlo desde el principio como un bote salvavidas.¹⁰¹¹

En una migración por etapas, conviene probar primero a pequeña escala

• qué control se quiere incrustar
• cómo se comportan el foco, la entrada, el DPI y el tema
• si esa configuración de host resulta realmente estable en la práctica

7. Cómo verlo cuando se parte de una aplicación existente

Aquí, lo existente importa más que lo nuevo.

7.1 Si ya tiene una aplicación WinForms

Antes de saltar directamente a WinUI, conviene verificar lo siguiente.

• ¿Se puede acercar al .NET actual?
• ¿Es necesaria la conversión a 64 bits?
• ¿Se pueden ordenar async/await, el manejo de excepciones, la configuración y los registros?
• ¿Se puede mejorar la mantenibilidad dividiendo pantallas o convirtiéndolas en UserControl?
• ¿Se pueden añadir solo las funciones de Windows necesarias mediante el Windows App SDK?

No es raro que algo que parece un problema de WinForms sea, en realidad, simplemente que

• la pantalla y la lógica están mezcladas
• los límites de los hilos son descuidados
• las responsabilidades de configuración, archivos, COM y base de datos están amontonadas

En ese caso, aunque se traslade a WinUI, el problema solo cambiará de nombre y permanecerá.

7.2 Si ya tiene una aplicación WPF

WPF facilita aprovechar los activos existentes.

• Activos XAML
• Binding
• Style/Template
• Command
• MVVM

El motivo para renunciar a esto debería ser bastante claro.

Por ejemplo, si

• se quiere renovar por completo la UI del producto
• se quiere tomar Fluent como eje principal
• se va a separar un módulo nuevo como un producto distinto
• se quiere acercarse a una experiencia nueva como producto exclusivo de Windows

esto se convierte en un motivo para considerar WinUI. Pero, si el único argumento es simplemente «porque WPF es antiguo», resulta débil.

7.3 Lo que realmente pesa suele ser lo que no es la UI

En la práctica, lo que resulta pesado suele ser, sorprendentemente, esto:

• ActiveX / OCX
• COM interop
• Informes propios
• Impresión
• Integración con Excel/Office
• DLL nativas
• Desajustes entre 32 y 64 bits
• Instalador, permisos, actualizaciones, firmas

Si se subestima esto, aunque se limpie solo la UI, el proyecto en su conjunto no se aligera.

Por eso, en la migración de una aplicación existente, lo prioritario es hacer un inventario de cada límite de dependencia, y no mirar únicamente el framework de UI.

8. Las cinco preguntas finales para cuando dude

Si al final sigue dudando, aplique estas cinco preguntas en orden.

8.1 ¿Los activos existentes son grandes?

• Grandes → Mantener básicamente la misma línea tecnológica existente
• Pequeños / inexistentes → Pasar a una selección de desarrollo nuevo

8.2 ¿Es imprescindible en esa aplicación una «experiencia moderna típica de Windows»?

• Imprescindible → WinUI es una opción sólida
• No tanto → Verificar si basta con WPF/WinForms

8.3 ¿Las pantallas se centran en formularios estándar o se necesita la expresividad propia de XAML?

• Centradas en formularios estándar → WinForms
• Importan los estilos/plantillas/Binding/MVVM → WPF

8.4 ¿Lo que quiere es una renovación total de la UI o la incorporación de funciones de Windows?

• Renovación total de la UI → Considerar WinUI
• Solo incorporación de funciones → Considerar primero el WPF/WinForms actual + Windows App SDK

8.5 ¿Puede explicar de antemano cómo gestionará la distribución, las actualizaciones y la operación?

• Aún es ambiguo → Con WinUI, definir pronto el packaging/deployment
• Se quiere apoyar fuertemente en la operación existente → WPF/WinForms suele generar menos fricción

Con estas cinco preguntas se puede acotar bastante la decisión. A modo de resumen final y simplificado, quedaría así:

• Formulario interno que se crea rápido → WinForms
• Aplicación empresarial de Windows que crece a largo plazo → WPF
• UI de producto Windows moderno y nuevo → WinUI
• Aprovechar lo existente modernizando solo las funciones de Windows → Framework actual + Windows App SDK

9. Resumen

La selección entre WinForms, WPF y WinUI no es un juego de ordenarlas de más antigua a más nueva y elegir la de más a la derecha.

Lo primero que hay que observar son estos cuatro puntos.

1. ¿Dónde están los activos existentes?
2. ¿Las pantallas se centran en formularios o en la expresividad?
3. ¿Una UI moderna típica de Windows es un requisito del producto?
4. ¿Cómo se gestionarán la distribución, las actualizaciones y la operación?

Si estos cuatro puntos están claros, la política queda prácticamente decidida.

• Si tiene una base grande de WinForms existente, continúe primero con WinForms
• Si tiene una base grande de WPF existente, continúe primero con WPF
• Si es nuevo y se centra en formularios estándar, use WinForms
• Si es nuevo y es una aplicación empresarial de Windows de tamaño medio a grande, use WPF
• Si es nuevo y la experiencia moderna de Windows en sí es un requisito, use WinUI
• Si solo quiere usar el Windows App SDK, no pase todo directamente a WinUI

Lo que más conviene evitar son estas tres cosas:

• descartar algo porque es antiguo
• elegir algo porque es nuevo
• empezar con la idea de que «ya se resolverá sobre la marcha»

El escritorio de Windows es un mundo en el que los activos, la distribución, la operación y las dependencias pesan más que la apariencia. Por eso, a la hora de elegir, también suele resultar más ganador fijarse en la menor fricción que en el brillo superficial.

10. Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Cuál es la diferencia entre WinUI 3 y WPF?

Ambos usan XAML, pero WinUI no es «simplemente un WPF nuevo». Difieren en la API base, el conjunto de controles, la estructura del proyecto, el planteamiento de implementación/empaquetado y la relación con el Windows App SDK. WPF es un framework de UI orientado a aplicaciones empresariales de tamaño medio a grande, con renderizado vectorial independiente de la resolución, enlace de datos, estilos/plantillas y comandos. WinUI, en cambio, forma parte del Windows App SDK y es un framework de UI moderno pensado desde el principio para Fluent, alto DPI y la experiencia actual de Windows. Es arriesgado considerarlo un simple reemplazo casual de WPF.

¿Cuál debería elegir para un desarrollo nuevo: WinForms, WPF o WinUI?

Depende del carácter de las pantallas y de los requisitos del producto. Si quiere crear rápidamente una herramienta interna pequeña o mediana centrada en controles estándar y formularios de entrada, WinForms sigue siendo bastante sólido. Si se trata de una aplicación empresarial de tamaño medio a grande con muchas pantallas en la que quiere aprovechar bien el enlace de datos, los estilos, las plantillas y MVVM, WPF suele ser la opción más segura en la mayoría de los casos. Si es un producto nuevo exclusivo de Windows en el que Fluent y una experiencia moderna de Windows están directamente vinculados al valor del producto, WinUI es una opción sólida. Cuando existen activos grandes ya desarrollados, lo primero que hay que considerar es continuar con esa misma línea tecnológica.

¿WPF y WinForms ya están anticuados?

No conviene descartarlos sin más. Tanto WinForms como WPF mantienen documentación y vías de migración activas sobre el .NET actual, y Microsoft los sigue tratando oficialmente como frameworks de UI de escritorio vigentes para Windows. Especialmente en aplicaciones empresariales, es habitual que los activos existentes, los controles de terceros, los informes e impresión, la integración con equipos y los procedimientos de distribución pesen más que la novedad del framework de UI. No es raro que, incluso en un desarrollo nuevo, WinForms o WPF resulten la opción con menos fricción.

¿Es necesario migrar a WinUI para usar las funciones más recientes de Windows?

No. El Windows App SDK y WinUI no son lo mismo: WinUI es la parte de framework de UI del Windows App SDK. El propio Windows App SDK puede añadirse a aplicaciones existentes en WPF, WinForms o Win32, y funciones como App Lifecycle, Windowing o Toast Notifications a veces pueden incorporarse manteniendo la UI actual. Es decir, existe un camino para modernizar solo las funciones de Windows necesarias sin abandonar el WPF/WinForms existente, y una migración total de la UI no es obligatoria.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.