My experience with .NET MAUI and why I ended up choosing PWA for side projects

What attracted me to .NET MAUI

What I like about .NET MAUI is that I already have familiarity with Visual Studio, C# and .NET. Additionally, I can reuse entities, validations and practically all the back-end logic, which speeds up development a lot.

For this reason I decided to work with MAUI. The first thing I did was build a very simple API on the back-end.

After finishing the API, I asked Claude Code (Opus 4.5) to build the entire interface and consume the API based on layout specifications I wrote in .md files.

The result was impressive: in less than a day I already had a functional project.

Development challenges

After generating the project, I started testing on Windows and quickly found numerous bugs.

Several iterations with the AI were needed, pointing out specific issues, in addition to several corrections I made manually.

In the end I managed to get the project working both on Windows and Android through manual testing.

The biggest problem I encountered was the difference between platforms.

• Code that worked perfectly on Android had issues on Windows.
• In some cases I had to create components specific to Windows.
• There were situations where even the AI couldn’t find a solution.

This was the biggest challenge during development.

Publishing the app on the Play Store

After the project was working, I went to publish it on Google Play.

That’s when the biggest shock came.

In addition to paying the fee of approximately US$ 25 (about R$ 100), I had to go through several bureaucratic processes:

• Produce screenshots.
• Fill out several forms.
• Configure policies and app information.
• Create a Closed Testing.

Closed Testing was the most complicated part.

It was necessary to get 12 testers to use the app for about 12 days before I could request public release.

Since I didn’t have that many people available, I had to pay to get those tests.

I even sent an email to Google explaining that the app was just a study side project, with only two screens for reading articles, already manually tested.

I asked if there was any way to reduce this requirement or receive some kind of exception.

The answer was simply: no.

Maintaining the MAUI project

Another point that bothered me was maintenance.

Each update required a new publishing process for Windows and Android.

This ends up generating a lot of work for a personal project that:

• Generates no revenue.
• Exists only for learning.
• Basically receives contacts from other developers asking for help or people offering services.

That was when I started looking for alternatives.

Deciding to test PWA

I decided to try a Progressive Web App (PWA).

The implementation was extremely simple.

Basically I needed:

• Add some icons.
• Configure a worker.js.

Claude Code itself did practically all of this implementation.

What I liked most about PWA

The PWA is, in practice, the website itself working as an app.

This means I don’t need to generate a specific version for each platform nor go through all the store bureaucracy.

Distribution happens directly from the website itself.

Although it’s a web application, the cache implemented by the Service Worker offers an experience very close to a native app in many scenarios.

Advantages of PWA

• Extremely fast implementation.
• Can work offline.
• Excellent caching system through Service Worker.
• Updates happen automatically when the site is updated.
• Does not require publishing in stores for distribution.
• No need to repeat bureaucratic processes with each update.
• A single project serves all platforms.
• Great for information systems, ERP, dashboards and administrative applications.

Disadvantages of PWA

• Many leaders still don’t know the technology and end up being afraid to adopt it.
• Has limitations in accessing the operating system.
• Cannot work directly with drivers.
• Does not access USB ports, Serial, processes, system services and other low-level resources.
• Still does not achieve the same performance as a truly native app in all scenarios.

Final considerations

My conclusion is relatively simple.

If I needed to develop an app that depended on specific operating system resources, such as industrial automation, device communication, drivers or deep integration with the OS, I would choose Flutter, .NET MAUI or even native development.

On the other hand, for applications such as:

• ERP.
• Internal systems.
• Portals.
• Corporate applications.
• Information systems.
• Reading articles.

Today I would probably choose a PWA.

Development is extremely fast, maintenance practically disappears, updates are instant, and there is no bureaucracy involved in publishing to stores.

The only challenge I still see is the adoption of the technology, since many leaders simply don’t know enough about PWA and therefore end up preferring more traditional solutions.