Minha experiência com .NET MAUI e por que acabei optando por PWA em side projects

O que me atraiu no .NET MAUI

O que eu gosto no .NET MAUI é o fato de já ter familiaridade com Visual Studio, C# e .NET. Além disso, consigo reaproveitar entidades, validações e praticamente toda a lógica do back-end, o que acelera bastante o desenvolvimento.

Por esse motivo resolvi trabalhar com MAUI. A primeira coisa que fiz foi montar uma API bem simples no back-end.

Após finalizar a API, pedi para o Claude Code (Opus 4.5) montar toda a interface e consumir a API com base em especificações de layout que escrevi em arquivos .md.

O resultado foi impressionante: em menos de um dia eu já tinha um projeto funcional.

Os desafios do desenvolvimento

Depois de gerar o projeto comecei a testar no Windows e rapidamente encontrei inúmeros bugs.

Foram necessárias diversas iterações com a IA apontando problemas específicos, além de várias correções feitas manualmente por mim.

No final consegui deixar o projeto funcionando tanto no Windows quanto no Android através de testes manuais.

O maior problema que encontrei foi a diferença entre plataformas.

• Código que funcionava perfeitamente no Android apresentava problemas no Windows.
• Em alguns casos precisei criar componentes específicos apenas para Windows.
• Houve situações em que nem a IA conseguia encontrar uma solução.

Esse foi o maior desafio durante o desenvolvimento.

Publicação do aplicativo na Play Store

Depois que o projeto estava funcionando, fui publicá-lo na Google Play.

Foi nesse momento que veio o maior susto.

Além de pagar a taxa de aproximadamente US$ 25 (cerca de R$ 100), precisei passar por diversos processos burocráticos:

• Produzir screenshots.
• Preencher vários formulários.
• Configurar políticas e informações do aplicativo.
• Criar um Closed Testing.

O Closed Testing foi a parte mais complicada.

Foi necessário conseguir 12 testadores que utilizassem o aplicativo durante cerca de 12 dias antes de poder solicitar a publicação pública.

Como eu não tinha essa quantidade de pessoas disponíveis, precisei pagar para conseguir esses testes.

Inclusive enviei um e-mail para o Google explicando que o aplicativo era apenas um side project de estudos, contendo somente duas telas para leitura de artigos, já testado manualmente.

Perguntei se havia alguma forma de reduzir essa exigência ou receber algum tipo de exceção.

A resposta foi simplesmente: não.

Manutenção do projeto MAUI

Outro ponto que me incomodou foi a manutenção.

Cada atualização exigia um novo processo de publicação para Windows e Android.

Isso acaba gerando bastante trabalho para um projeto pessoal que:

• Não gera receita.
• Existe apenas para aprendizado.
• Recebe basicamente contatos de outros desenvolvedores pedindo ajuda ou pessoas oferecendo serviços.

Foi nesse momento que comecei a procurar alternativas.

Decidindo testar PWA

Resolvi experimentar um Progressive Web App (PWA).

A implementação foi extremamente simples.

Basicamente precisei:

• Adicionar alguns ícones.
• Configurar um worker.js.

O próprio Claude Code fez praticamente toda essa implementação.

O que mais gostei no PWA

O PWA é, na prática, o próprio site funcionando como aplicativo.

Isso significa que não preciso gerar uma versão específica para cada plataforma e nem passar por toda a burocracia das lojas.

A distribuição acontece diretamente pelo próprio site.

Apesar de ser uma aplicação web, o cache implementado pelo Service Worker oferece uma experiência muito próxima de um aplicativo nativo em diversos cenários.

Vantagens do PWA

• Implementação extremamente rápida.
• Pode funcionar offline.
• Excelente sistema de cache através do Service Worker.
• Atualizações acontecem automaticamente quando o site é atualizado.
• Não exige publicação em lojas para distribuição.
• Não precisa repetir processos burocráticos a cada atualização.
• Um único projeto atende todas as plataformas.
• Ótimo para sistemas de informação, ERP, dashboards e aplicações administrativas.

Desvantagens do PWA

• Muitas lideranças ainda desconhecem a tecnologia e acabam tendo receio de adotá-la.
• Possui limitações de acesso ao sistema operacional.
• Não consegue trabalhar diretamente com drivers.
• Não acessa portas USB, Serial, processos, serviços do sistema e outros recursos de baixo nível.
• Ainda não alcança a mesma performance de um aplicativo realmente nativo em todos os cenários.

Considerações finais

Minha conclusão é relativamente simples.

Se eu precisasse desenvolver um aplicativo que dependesse de recursos específicos do sistema operacional, como automação industrial, comunicação com dispositivos, drivers ou integração profunda com o SO, eu escolheria Flutter, .NET MAUI ou até mesmo desenvolvimento nativo.

Por outro lado, para aplicações como:

• ERP.
• Sistemas internos.
• Portais.
• Aplicações corporativas.
• Sistemas de informação.
• Leitura de artigos.

Hoje eu provavelmente escolheria um PWA.

O desenvolvimento é extremamente rápido, a manutenção praticamente desaparece, as atualizações são instantâneas e não existe toda a burocracia envolvida na publicação em lojas.

O único desafio que ainda vejo é a adoção da tecnologia, já que muitas lideranças simplesmente não conhecem o suficiente sobre PWA e, por isso, acabam preferindo soluções mais tradicionais.