- El ecosistema de desarrollo de apps nativas en Windows, tras décadas de fragmentación de frameworks y rediseños repetitivos, sigue sin ofrecer una productividad real para desarrolladores incluso en 2025
- Desde Win32, pasando por MFC, WinForms, WPF, WinRT y UWP, hasta WinUI 3, a pesar de 7 etapas de evolución de frameworks de UI, en muchos casos ni siquiera es posible implementar funciones básicas usando solo las APIs más recientes
- Funciones cotidianas como el ícono en la bandeja del sistema o la interceptación de atajos globales siguen dependiendo de llamadas a Win32 mediante P/Invoke, lo que le quita sentido a adoptar frameworks modernos
- Incluso al compilar con .NET AOT una app utilitaria simple, se genera un binario de más de 9 MiB, y además existe la barrera práctica de que los certificados de firma de código para distribuir con MSIX cuestan entre $200 y $300 al año
- El hecho de que apps importantes de Microsoft (VS Code, Outlook, el menú Inicio) estén hechas con tecnologías web demuestra que el desarrollo nativo en Windows ya no es una prioridad ni siquiera dentro de Microsoft
Contexto: qué se construyó
- Durante el desarrollo de la app utilitaria exclusiva para Windows “Display Blackout” quedaron en evidencia los problemas del entorno actual de desarrollo de apps nativas
- Esta app ofrece la función de apagar con una superposición negra las pantallas laterales mientras se juega en una configuración de múltiples monitores
- Las funciones necesarias incluyen enumeración de pantallas, cálculo de límites, manejo de atajos globales, mostrar un ícono en la bandeja, ejecución automática al iniciar, guardado de configuración, etc.
- Ya existían scripts en AutoHotkey y apps de Microsoft Store, pero se intentó desarrollarla directamente con fines de aprendizaje y para mejorar la UI
- El resultado fue confirmar que el entorno de desarrollo de apps nativas en Windows es extremadamente complejo e ineficiente
Historia de la programación en Windows
- Al principio, la única opción era la API Win32 basada en C, y esa API sigue vigente hasta hoy
- Luego MFC, basado en C++, agregó abstracciones orientadas a objetos como clases y plantillas sobre Win32
- Con la llegada de .NET 1.0 (2002) aparecieron el lenguaje C#, una VM de bytecode con JIT y manejo automático de memoria, mientras que Windows Forms era un wrapper de las APIs de ventanas y controles de Win32
- WPF en .NET 3.0 (2006) introdujo el lenguaje de marcado XAML y fue el primer intento de alejarse de la dependencia de Win32 mediante renderizado de controles con GPU
- WinRT en Windows 8 (2012) introdujo un modelo de apps en sandbox con el objetivo de unificar escritorio, tablet y teléfono, pero su estructura XAML difería sutilmente de la de WPF y generó confusión
- UWP en Windows 10 (2015) relajó parcialmente las restricciones del sandbox, pero no alcanzó el nivel de permisos de escritorio de WPF, y algunas funciones del sistema operativo (notificaciones push, live tiles, distribución por Microsoft Store) quedaron limitadas a WinRT/UWP
- Esto llevó a que apps existentes como Chrome y Microsoft Office adoptaran arquitecturas incómodas conectando apps puente de WinRT/UWP mediante IPC
- Windows App SDK en Windows 11 (2021) abrió funciones exclusivas de WinRT/UWP a apps estándar tanto en C++ como en .NET, e incluye WinUI 3, una nueva biblioteca de controles basada en XAML
- Resumen de la evolución de frameworks de UI:
Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3
El dilema al elegir cómo desarrollar
- Para desarrollar apps con WinUI 3 existen tres caminos:
- C++: binarios ligeros y fácil interoperabilidad con la API C de Win32 — pero sin seguridad de memoria
- C#/XAML + despliegue dependiente del framework: incluso en Windows 11 moderno solo viene preinstalado .NET 4.8.1, así que en la primera instalación aparece un deficiente cuadro de diálogo para descargar bibliotecas de .NET
- C#/XAML + .NET AOT: incluye en el binario todo el runtime de .NET (VM, GC, biblioteca estándar), por lo que incluso una app simple genera un binario de más de 9 MiB
- El intento de mantener bindings para Rust (
windows-app-rs) fue archivado - El método de distribución también implica dolor al elegir:
- El formato MSIX requiere un certificado de firma de código, que para quienes viven fuera de EE. UU. cuesta entre $200 y $300 al año
- La instalación lateral sin firma requiere un confuso comando de PowerShell que solo puede usarse desde una terminal con privilegios de administrador
- El registro en Microsoft Store fue rechazado con el argumento de que no ofrecía un “valor original y sostenido”
Funciones imposibles incluso con el SDK más reciente
| Función | Soporte en Windows App SDK |
|---|---|
| Enumeración de pantallas | Parcialmente posible (no se puede usar un bucle foreach; para detectar cambios se necesita P/Invoke) |
| Colocación de ventanas negras no activables | Parcialmente posible (para que no se activen se necesita P/Invoke) |
| Interceptación de atajos globales de teclado | No es posible — requiere P/Invoke |
| Ejecución automática al iniciar | Posible (hay una API que se integra con la configuración del sistema) |
| Guardado persistente de configuración | Posible |
| Ícono en la bandeja + menú | No es posible — requiere P/Invoke, y el estilo del menú no está estandarizado |
- El estilo de los menús del ícono en bandeja varía de una app a otra y no existe un estándar coherente en todo el sistema operativo
- En el paso de WPF a WinUI 3 desaparecieron incluso funciones básicas como el ajuste automático del tamaño de la ventana
Las limitaciones estructurales de la interoperabilidad entre C# y Win32
- La herramienta moderna de P/Invoke CsWin32 tiene un bug por el que no envuelve correctamente las cadenas dentro de structs
- La documentación de CsWin32 explica que, como C# no tiene una forma idiomática de representar el tipo de parámetro básico de Win32
[optional, out], genera dos versiones del mismo método - Incluso ahora, casi 20 años después del lanzamiento de WPF (2006), el boilerplate para escribir clases de enlace de UI casi no ha mejorado
- Sigue siendo necesario convertir todas las propiedades en pares getter/setter, agregar validaciones para evitar valores iguales y llamar manualmente a eventos de notificación
- En 20 años no se ha añadido a C# una solución a nivel de lenguaje equivalente a decoradores o proxies de JavaScript
- CsWin32 tiene un changelog pobre y sigue en una versión anterior a 1.0, por lo que parece posible que el proyecto sea abandonado en pocos años
Conclusión: por qué Electron es la respuesta
- En este momento, Microsoft no prioriza el desarrollo de apps nativas
- Los rastreadores de issues relacionados están llenos de bugs y reportes, pero casi no hay respuestas de ingenieros de Microsoft
- El changelog de Windows App SDK se centra en agregar APIs de machine learning
- El hecho de que las principales apps de Microsoft, como VS Code, Outlook y el menú Inicio, estén hechas con tecnologías web lo demuestra
- La comunidad se está moviendo hacia frameworks de UI de terceros como Avalonia y Uno Platform
- Estos heredan la filosofía de WPF y refuerzan el soporte multiplataforma
- Por ahora, frameworks basados en web como Electron o Tauri son una opción más realista
- La combinación de TypeScript/React/CSS es más productiva que C#/XAML
- También permite acceso a la API Win32
-
Tauri** usa** el WebView del sistema**, por lo que** no necesita incluir Chromium
- El runtime de WebView2 se actualiza cada 4 semanas, mientras que el .NET del sistema está fijo en 4.8.1
- Si Microsoft impulsara mejoras en Windows App SDK y simplificara el sistema de distribución, todavía podría haber posibilidades de recuperación
- Pero por ahora la mayoría de los desarrolladores no lo espera
- En conclusión, se cierra con la decisión de “elegir la pila web”
- El reciente anuncio de Microsoft sobre su enfoque en la calidad de Windows incluye que se usará más WinUI 3 en todo el sistema operativo, pero no está claro si eso se traducirá en mejoras reales
3 comentarios
Gracias por normalizarlo con Electron...
Ojalá salga pronto el WYSIWYG de WinUI 3.
Opiniones de Hacker News
Yo también creo, como otras personas, que lo correcto es seguir usando Win32
Desde la perspectiva de alguien que ha desarrollado con Win32 durante mucho tiempo, las funciones necesarias se pueden implementar de sobra en un ejecutable independiente de menos de 8 KB
Enumerar pantallas, crear ventanas, enganchar atajos de teclado, registrar el programa al inicio, guardar configuraciones, mostrar iconos en la bandeja: todo eso se puede hacer con llamadas a la API de apenas unos cientos de bytes
Pero en 2026, escribir un proyecto nuevo en un lenguaje sin seguridad de memoria (C++) ya va contra los tiempos
Aun así, si es una app con muy poca entrada no confiable, no hay necesidad de dejarse llevar por la propaganda
_UNICODE, puedes hacer lo mismo en la mitad de tiempo con .NET FrameworkCreo que debería volver el movimiento de “NoFramework” y regresar a la era del RAD
Pero conviene pensarlo bien antes de elegir C++ para un proyecto nuevo
También se puede usar Win32 desde lenguajes con seguridad de memoria, por ejemplo windows-rs
En esa época, Borland Delphi era la herramienta más popular
Si no son apps existentes de WinRT, UAP o UWP, es mejor evitar WinUI 3.0 y WinAppSDK
Conviene seguir usando tecnologías probadas como Win32, MFC, WinForms o WPF,
y fuera del ecosistema de Microsoft valdría la pena considerar Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI, etc.
WinUI 3.0 está tan mal que incluso Microsoft está intentando pasarla a la comunidad como proyecto open source
Después, WinJS se convirtió en un framework web open source y perdió el soporte oficial
Entrada relacionada del blog
Soy desarrollador de sistemas embebidos, y sigue siendo fácil hacer programas GUI Win32 que se comuniquen con dispositivos
Código de la época de XP siguió funcionando tal cual en Windows 11, y hasta proyectos de VC6 compilan sin problema al abrirlos en Visual Studio 2022
Esta compatibilidad hacia atrás es algo difícil de ver en otras plataformas
Cocoa de Apple tiene una estructura “elegante”, pero en la práctica es compleja y su documentación no ayuda
La API Win32 pura sigue siendo una opción práctica
Si haces tú mismo un wrapper parecido a MFC en C++, puedes terminarlo en 2 o 3 semanas y después tendrás control total
Gracias a la sólida compatibilidad hacia atrás de Microsoft, las apps basadas en Win32 son estables a largo plazo
Puedes ver aquí un ejemplo actualizado durante más de 10 años: aquí
Los colores del sistema y los controles están hardcodeados, así que chocan con los temas oscuros
Solo algunas partes de la UI, como menús, cuadros de mensaje o diálogos de archivo, soportan modo oscuro, lo que rompe la consistencia
Para más discusión, ver este texto
Hoy se mantiene como open source y ya va por la versión 10
Por experiencia haciendo varias apps para Windows,
(1) la API Win32 es vieja, pero muy estable, y
(2) hay que evitar los toolkits de UI propiedad de Microsoft — al final terminas necesitando control al nivel de Win32
La mayoría de las tecnologías de UI que Microsoft creó en los últimos 20 años fueron variaciones de WPF
Si hubieran seguido desarrollando WPF, a estas alturas habría sido el estándar del desarrollo de UI
Desde el punto de vista del usuario, las apps nativas son rápidas y agradables, pero desarrollarlas es un verdadero caos complejo
Por eso apps como Outlook y Teams van empeorando cada vez más
Es difícil imitar la sensación nativa en cosas como el foco o la navegación por teclado
Ver proyecto Electrobun
No estoy de acuerdo con eso de que “hacer proyectos nuevos en C++ es un crimen”
En una GUI, el rendimiento y el control importan más que la seguridad, y C++ sigue siendo un lenguaje probado
Qt sigue siendo uno de los mejores frameworks GUI incluso en 2026, y trae funciones de seguridad de memoria integradas
Me pregunto por qué el runtime moderno de .NET no viene incluido por defecto en Windows 11
Parece otro caso en el que Microsoft renunció a ofrecer una experiencia de usuario consistente
distribuirlas todas por Windows Update no es realista
En su lugar, se pueden distribuir como ejecutables autónomos compilados con AOT (unos 9 MiB)
Son mucho más pequeños y eficientes que Electron
Ahora es mejor empaquetar también las DLL
así que se volvió difícil integrarlo dentro del SO
Se separó de las actualizaciones del sistema operativo para mantener un ciclo de lanzamientos rápido
mientras que .NET Core debe instalarse por separado
Después de mucho tiempo, volví a hacer una app para Windows y Mac con Tauri
Desarrollar y compilar fue fácil, pero por problemas de firma de código mis colegas no pudieron instalarla
En Mac se resolvió con un comando de terminal, pero en Windows hubo que desactivar Smart App Control
y esa función no se puede volver a activar sin reinstalar
Entiendo el objetivo de seguridad, pero no esperaba que el proceso de instalación fuera tan difícil
La respuesta a la pregunta “¿por qué no usar Electron?” es simple:
las apps de Electron ofrecen una mala experiencia de usuario
Desarrollarlas es fácil, pero a costa del rendimiento y la calidad
Si quieres hacer un buen producto, aunque sea más difícil, tienes que ir por lo nativo
Personalmente, creo que C# es mucho mejor que TypeScript