- O ecossistema de desenvolvimento de apps nativos no Windows, após décadas de rupturas entre frameworks e redesenhos repetitivos, continua sem oferecer produtividade real de desenvolvimento mesmo em 2025
- De Win32, passando por MFC, WinForms, WPF, WinRT e UWP, até o WinUI 3, mesmo após 7 etapas de evolução dos frameworks de UI, ainda há muitos casos em que nem funcionalidades básicas podem ser implementadas apenas com as APIs mais recentes
- Recursos cotidianos como ícone na bandeja e interceptação de atalhos globais ainda dependem de chamadas Win32 via P/Invoke, o que esvazia o sentido de adotar frameworks modernos
- Mesmo ao compilar um utilitário simples com .NET AOT, é gerado um binário com mais de 9 MiB, e certificados de assinatura de código para distribuição via MSIX representam uma barreira prática de US$ 200–300 por ano
- O fato de aplicativos importantes da própria Microsoft, como VS Code, Outlook e o Menu Iniciar, serem implementados com tecnologias web mostra que o desenvolvimento nativo para Windows já não é prioridade nem dentro da Microsoft
Contexto: o que foi criado
- Durante o desenvolvimento do utilitário exclusivo para Windows “Display Blackout”, ficaram expostos os problemas do ambiente atual de desenvolvimento de apps nativos
- O app oferece, em ambientes com múltiplos monitores, a função de apagar visualmente as telas laterais com um overlay preto enquanto se joga
- As funções necessárias incluem enumeração de displays, cálculo de limites, tratamento de atalhos globais, exibição de ícone na bandeja, execução automática na inicialização e salvamento de configurações
- Já existiam scripts em AutoHotkey e apps na Microsoft Store, mas a tentativa foi feita para fins de aprendizado e melhoria da UI
- Como resultado, ficou evidente que o ambiente de desenvolvimento nativo no Windows é extremamente complexo e ineficiente
A história da programação no Windows
- No início, a única opção era a API Win32 baseada em C, que continua válida até hoje
- O MFC, baseado em C++, adicionou abstrações orientadas a objetos como classes e templates sobre o Win32
- Com a chegada do .NET 1.0 (2002), surgiram a linguagem C#, a VM de bytecode com JIT e o gerenciamento automático de memória, enquanto o Windows Forms funcionava como um wrapper das APIs de janelas e controles do Win32
- O WPF do .NET 3.0 (2006) introduziu a linguagem de marcação XAML e foi a primeira tentativa de reduzir a dependência de Win32 com renderização de controles via GPU
- O WinRT do Windows 8 (2012) introduziu um modelo de apps em sandbox, buscando unificar desktop, tablet e celular, mas a estrutura em XAML era sutilmente diferente da do WPF, gerando confusão
- O UWP do Windows 10 (2015) relaxou parte das limitações do sandbox, mas ainda ficou abaixo do nível de permissões desktop do WPF, e alguns recursos do sistema operacional (notificações push, live tiles, distribuição pela Microsoft Store) permaneceram restritos a WinRT/UWP
- Isso levou apps existentes, como Chrome e Microsoft Office, a adotar arquiteturas estranhas conectando apps-ponte WinRT/UWP por IPC
- O Windows App SDK do Windows 11 (2021) abriu recursos antes exclusivos de WinRT/UWP para apps padrão em C++ e .NET, além de incluir o WinUI 3, uma nova biblioteca de controles baseada em XAML
- Resumo da evolução dos frameworks de UI:
Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3
O dilema da escolha da forma de desenvolvimento
- Existem três caminhos para desenvolver apps com WinUI 3:
- C++: binários enxutos, interoperabilidade fácil com a API C do Win32 — porém sem segurança de memória
- C#/XAML + distribuição dependente de framework: mesmo no Windows 11 mais recente, apenas o .NET 4.8.1 vem pré-instalado, o que resulta em uma péssima experiência para o usuário com diálogo de download de bibliotecas .NET na primeira instalação
- C#/XAML + .NET AOT: inclui todo o runtime do .NET (VM, GC, biblioteca padrão) no binário — até apps simples geram binários com mais de 9 MiB
- A tentativa de manter bindings em Rust (
windows-app-rs) foi arquivada - A forma de distribuição também é uma dor de cabeça:
- O formato MSIX exige certificado de assinatura de código, com custo anual de US$ 200–300 para quem mora fora dos EUA
- O sideload sem assinatura exige comandos obscuros de PowerShell utilizáveis apenas em terminal com privilégios de administrador
- O cadastro na Microsoft Store foi rejeitado sob a justificativa de não oferecer “valor original e duradouro”
Recursos impossíveis até mesmo no SDK mais recente
| Recurso | Suporte no Windows App SDK |
|---|---|
| Enumeração de displays | Parcial (foreach não é possível, e detectar mudanças exige P/Invoke) |
| Posicionamento de janela preta não ativável | Parcial (non-activating exige P/Invoke) |
| Interceptação de atalhos globais de teclado | Não — requer P/Invoke |
| Execução automática na inicialização | Sim (há API integrada às configurações do sistema) |
| Persistência de configurações | Sim |
| Ícone na bandeja + menu | Não — requer P/Invoke, e o estilo do menu não é padronizado |
- O estilo dos menus do ícone na bandeja varia de app para app, sem padrão consistente em todo o sistema operacional
- Na transição de WPF para WinUI 3, até funcionalidades básicas como redimensionamento automático da janela desapareceram
Limitações estruturais de C# e da interoperabilidade com Win32
- A ferramenta moderna de P/Invoke CsWin32 tem um bug que impede encapsular corretamente strings dentro de structs
- A documentação do CsWin32 afirma que o C# não possui uma forma idiomática de representar o tipo de parâmetro básico da API Win32,
[optional, out], e por isso gera duas versões do mesmo método - Mesmo quase 20 anos após o lançamento do WPF (2006), o boilerplate para escrever classes de binding de UI praticamente não melhorou
- Ainda é necessário repetir código para converter todas as propriedades em pares getter/setter, proteger contra valores iguais e disparar chamadas de evento
- Uma solução em nível de linguagem equivalente a decorators/proxies do JavaScript não foi adicionada ao C# em 20 anos
- O CsWin32 tem changelog fraco e continua em versão anterior à 1.0, o que faz parecer que o projeto pode ser abandonado nos próximos anos
Conclusão: por que Electron é a resposta
- Atualmente, a Microsoft não prioriza o desenvolvimento de apps nativos
- O issue tracker relacionado está cheio de bugs e relatórios, mas quase não há respostas de engenheiros da Microsoft
- O changelog do Windows App SDK está focado principalmente em adicionar APIs de machine learning
- Isso é reforçado pelo fato de apps importantes da própria Microsoft, como VS Code, Outlook e o Menu Iniciar, serem implementados com tecnologias web
- A comunidade está migrando para frameworks de UI de terceiros como Avalonia e Uno Platform
- Eles herdam a filosofia do WPF e reforçam o suporte multiplataforma
- No cenário atual, frameworks web como Electron e Tauri são escolhas mais realistas
- A combinação TypeScript/React/CSS é mais produtiva que C#/XAML
- Também é possível acessar a API Win32
-
O Tauri usa a WebView do sistema**, eliminando a necessidade de empacotar o Chromium
- O runtime do WebView2 é atualizado a cada 4 semanas, enquanto o .NET do sistema permanece travado no 4.8.1
- A situação ainda poderia se recuperar se a Microsoft avançasse na melhoria do Windows App SDK e na simplificação do sistema de distribuição
- Mas, no momento, a maioria dos desenvolvedores não espera isso
- Em resumo, a conclusão é: “vou escolher a stack web”
- O recente anúncio da Microsoft sobre foco na qualidade do Windows inclui a intenção de usar mais WinUI 3 em todo o sistema operacional, mas ainda não está claro se isso levará a melhorias concretas
3 comentários
Ainda bem que normalizaram isso com Electron...
Tomara que um WYSIWYG para WinUI 3 saia algum dia.
Opiniões do Hacker News
Eu também acho que, como outras pessoas, faz sentido continuar com Win32
Do ponto de vista de quem desenvolve com Win32 há muito tempo, dá para implementar os recursos necessários com um executável independente de menos de 8 KB
Enumerar monitores, criar janelas, interceptar atalhos, registrar na inicialização, salvar configurações, exibir ícone na bandeja — tudo isso é possível com chamadas de API de algumas centenas de bytes
Mas, em 2026, escrever um novo projeto em uma linguagem sem segurança de memória (C++) é algo anacrônico
Ainda assim, se for um app com quase nenhuma entrada não confiável, não há por que se deixar levar pela propaganda
_UNICODE, dá para fazer a mesma coisa na metade do tempo com .NET FrameworkAcho que o movimento “NoFramework” deveria voltar para nos levar de volta à era RAD
Mas é preciso pensar bem antes de escolher C++ em um projeto novo
Também dá para usar Win32 em linguagens com segurança de memória — por exemplo, windows-rs
Na época, Borland Delphi era a ferramenta mais popular
Se não forem apps antigos de WinRT, UAP ou UWP, é melhor evitar WinUI 3.0 e o WinAppSDK
É mais sensato continuar usando tecnologias comprovadas como Win32, MFC, WinForms e WPF,
e, fora do ecossistema da Microsoft, vale considerar Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI etc.
O WinUI 3.0 é tão bagunçado que até a própria Microsoft está tentando repassá-lo como open source para a comunidade
Depois, o WinJS virou um framework web open source e perdeu o suporte oficial
Post relacionado no blog
Sou desenvolvedor de embarcados, e ainda é fácil criar um programa GUI em Win32 para se comunicar com dispositivos
Código da época do XP continuou funcionando no Windows 11, e até projetos de VC6 abrem no Visual Studio 2022 e compilam sem problemas
Esse tipo de retrocompatibilidade é difícil de ver em outras plataformas
O Cocoa da Apple é “elegante” na estrutura, mas na prática é complexo e mal documentado
A API Win32 pura ainda é uma escolha prática
Se você criar em C++ um wrapper parecido com MFC por conta própria, dá para terminar em 2 ou 3 semanas e depois ter controle total
Graças à forte retrocompatibilidade da Microsoft, apps baseados em Win32 permanecem estáveis no longo prazo
Dá para ver um exemplo atualizado por mais de 10 anos aqui
As cores do sistema e os controles são hardcoded, então entram em conflito com temas escuros
Só parte da UI — como menus, message boxes e caixas de diálogo de arquivo — suporta modo escuro, o que quebra a consistência
Veja este texto para a discussão relacionada
Hoje ele continua mantido como open source e já chegou à versão 10
Pela minha experiência criando vários apps para Windows,
(1) a API Win32 é antiga, mas extremamente estável, e
(2) toolkits de UI da Microsoft devem ser evitados — no fim você acaba precisando de controle no nível do Win32
A maior parte das tecnologias de UI criadas pela Microsoft nos últimos 20 anos foi alguma variação do WPF
Se a Microsoft tivesse continuado evoluindo o WPF, hoje ele provavelmente seria o padrão do desenvolvimento de UI
Do ponto de vista do usuário, apps nativos são rápidos e bons, mas o desenvolvimento é realmente um caos complicado
Esse também é o motivo de apps como Outlook e Teams estarem ficando cada vez piores
É difícil imitar a sensação de um app nativo em coisas como foco e navegação por teclado
Veja o projeto Electrobun
Não concordo com a ideia de que “fazer projeto novo em C++ é crime”
Em GUI, desempenho e controle importam mais do que segurança, e C++ continua sendo uma linguagem comprovada
Qt ainda é um dos melhores frameworks de GUI em 2026 e já traz recursos de segurança de memória embutidos
Fico me perguntando por que o runtime mais recente do .NET não vem por padrão no Windows 11
Isso parece outro caso em que a Microsoft desistiu de oferecer uma experiência de usuário consistente
então distribuí-las todas pelo Windows Update é algo irrealista
Em vez disso, dá para distribuir como executável independente compilado com AOT (cerca de 9 MiB)
É muito menor e mais eficiente do que Electron
Hoje é melhor empacotar junto com as DLLs
o que dificultou embuti-lo no sistema operacional
A ideia foi separá-lo das atualizações do sistema para manter um ciclo de releases rápido
enquanto o .NET Core precisa ser instalado separadamente
Fazia tempo que eu não criava um app para Windows e Mac com Tauri,
e o desenvolvimento e build foram fáceis, mas meus colegas não conseguiram instalar por causa de problemas de assinatura de código
No Mac, isso foi resolvido com comandos no terminal, mas no Windows foi preciso desativar o Smart App Control
e, sem reinstalar o sistema, não dá para ativá-lo de novo
Entendo a intenção de segurança, mas não imaginava que o processo de instalação seria tão difícil
A resposta para a pergunta “por que não usar Electron?” é simples —
apps em Electron oferecem uma experiência ruim para o usuário
O desenvolvimento é fácil, mas à custa de desempenho e qualidade
Se você quer criar um bom produto, precisa ir para o nativo, mesmo que seja mais difícil
Pessoalmente, acho C# muito melhor do que TypeScript