Know C# and JavaScript? You’re Already a Mobile Developer
Have you ever tried to help your child with Dutch dictation when your own Dutch isn't perfect? I have. For almost a year now, I’ve been working on a mobile app on and off because of it. It wasn’t a side project or a business idea. It started at my kitchen table.
My child needed to practice Dutch dictation. As parents, we wanted to help, but to be honest, our own Dutch wasn’t good at all. The last thing we wanted was for him to practice with our accent and pick up our mistakes. It was important to me that he heard every word with correct, native Dutch pronunciation. I also wanted him to practice as much as he liked, whenever he liked, without depending on us.
So I built an app. I already knew web development, JavaScript, CSS and especially C#, so the choice was easy: .NET MAUI with Blazor Hybrid.
What are .NET MAUI and Blazor Hybrid?
.NET MAUI (Multi-platform App UI) is Microsoft’s framework for building native apps for Android, iOS, Windows and macOS from a single codebase. Blazor Hybrid lets you build the UI of those apps with Razor components (HTML, CSS and C#). The UI is rendered inside a native WebView, while your C# code runs directly on the device with full access to .NET and platform APIs.
In short, you build it like a web app, but it’s packaged, installed and run like a native mobile app.
Why Blazor and not XAML?
The default way to build a UI in .NET MAUI is XAML, an XML-based markup language. I tried it first. It didn’t take long before I was lost. I couldn’t figure out how to use it properly or how its components connect and work together. That XML syntax never felt natural to me.
HTML, CSS and JavaScript, on the other hand, were old friends. With Blazor, I could use them from day one and see results quickly, instead of learning a new UI language first. JavaScript still has its place, too. In a few spots, I used Blazor’s JS interop to add visual effects and animations to the UI by calling small JavaScript functions from my C# code.
Why it felt so easy
The core of the dictation app came together surprisingly fast. A few reasons:
- Dependency injection out of the box. Text-to-speech, storage, settings: each one is a service, registered in .NET’s built-in DI container and injected wherever it’s needed. A new feature usually means writing a new service, registering it and using it in a component.
- Testable code. The logic lives in plain C# services, so unit testing works like in any other .NET project (more on this below).
- The whole .NET ecosystem. NuGet packages, familiar tooling and Visual Studio, all available from day one.
- Code sharing. The same Razor components can be reused in a Blazor web app, so mobile, desktop and web can share a lot of code.
- Works offline. Everything runs on the device. No server needed.
The hard part: making it look good
The app worked. It didn’t look good, though, and I have to be honest about that. Writing the logic was the easy part. Making the UI and UX polished and pleasant was a different story. For a long time, my app was like a car with a great engine and a cardboard body. That was just simply because I’m not the UI guy.
Where AI tools actually helped
About six months ago, I started using Claude and GitHub Copilot for the UI. As someone who is usually skeptical of these tools, I was genuinely surprised. Layouts, colors, spacing, small interactions: things that used to cost me hours of trial and error came together quickly. Finally, the app looked as good as it worked. That turned out to be the winning combination for me: a framework that uses the skills I already have, plus tools that fill the gaps where I’m weaker.
From one app to many
That experience gave me confidence and I started building the apps I’d always wanted:
- A language-learning app for Dutch, designed around the way I learn best
- A micro-habit tracker
- A journaling app
- MVPs for three other ideas, to quickly test whether they’re worth pursuing
Most of these already exist as commercial apps, usually with a monthly subscription or a one-time price. More importantly, nobody really knows what happens to the personal data you put into them. With my own versions, my data stays with me and I pay nothing (except, of course, for my time and some tokens).
Lessons learned working with AI tools
These come purely from my own experience. The tools change every month, so some of these points may not age well.
- Define the architecture yourself, first. Before asking for help, decide how files are organized, how services are structured, how tests are written and how the projects connect. Write it down and insist that the AI follows it.
- Watch out for unnecessary dependencies. AI tools sometimes add libraries or NuGet packages that aren’t needed at all and make the project far more complicated than it should be. (I wrote more about this in my other post: A weekend and a startup’s missing milliseconds.)
- Watch out for duplicated code and styles. With Blazor, AI assistants tend to repeat themselves. A CSS change on one page gets copied into other pages instead of being defined once and reused. Push for shared styles and components early. Otherwise, one small change later means editing many places.
- Work iteratively and review every change. Move in small steps, task by task. Check what changed and why. If something doesn’t make sense, ask for it to be redone. Stay involved at every step. These tools can make your code so complex, so quickly, that you no longer know what lives where.
- Separate the logic from the UI. Keep as much logic as possible out of the UI. Unit testing becomes much easier and meaningful tests protect your core logic as the app grows. You can even ask the AI assistant to test the app for you. I was surprised to see it launch the app and take screenshots to check whether a style or a piece of logic works the way I intended.
- Ask for an onboarding document. Ask the AI to write a guide for a new developer joining the project and keep it updated as the project grows. If you ever get lost or lose access to these tools, you can still understand and continue the work yourself.
- Don’t count on the official skills, at least for now. Microsoft offers recommended skills for .NET and MAUI that you can add to AI coding assistants. I tried them and they didn’t help me at all. They may improve but interest in those skills and their development, seems to be fading.
Above all, never take their output at face value. Review it, test it and double-check it. (See also: Should we trust LLMs?)
The challenges you should know about
It’s not all sunshine (but then again, neither is the Dutch weather). A few things to be aware of when developing an app with MAUI .Net:
- Native features can be tricky. When you need deep access to platform-specific features, things get harder and you may need to write platform-specific code.
- Startup time. Apps can be noticeably slow to start, especially on Android.
- App size. Apps tend to be larger than fully native ones.
- WebView limitations. The UI runs inside a WebView, so it doesn’t always feel exactly native and heavy animations can struggle. From time to time, you’ll also notice small hiccups in the UI, like a brief stutter or delay. In my case, that was rare.
- Debugging on real devices can be frustrating. Hot reload in particular doesn’t always work reliably, so you may restart the app more often than you’d like.
- A smaller community than some other cross-platform frameworks, which means fewer ready-made answers and packages.
A note on iOS and Android
If you only have a Windows machine, keep in mind that building and debugging for iOS requires access to a Mac. Plan for that before you commit to iOS.
Get Babak Arjmandnia’s stories in your inbox
Join Medium for free to get updates from this writer.
Android on Windows, on the other hand, is a pleasure to work with. Wireless debugging lets you deploy and debug without plugging your phone into your computer. You can also test on several devices at the same time, which makes checking different screens and Android versions much faster.
When should you use it?
A great fit when:
- You or your team already know .NET and web technologies
- You want to build an MVP quickly
- You’re building internal, business or data-driven apps with forms, lists and dashboards
- You already have a Blazor web app and want mobile and desktop versions
- You’re building personal tools where privacy and control matter
Look elsewhere when:
- You’re building games or graphics-heavy apps
- Your app depends heavily on advanced native features
- Startup speed and app size are critical
There are other cross-platform options, such as Flutter and React Native, each with its own strengths. I haven’t used them myself, so I won’t compare them. But if you already live in the .NET world, MAUI with Blazor Hybrid is a very natural choice.
Back to the kitchen table
What started as a small app for my child’s dictation practice turned into a whole collection of personal tools. If you know C#, HTML, CSS and JavaScript, you already have most of what you need to build mobile apps. Add AI tools for the design, and the barrier gets even lower.
The best part has nothing to do with code, though. My child now asks to practice dictation with the app, all on his own. He even comes up with ideas to make it better and he has been my biggest cheerleader for releasing it publicly. Right now, I’m fighting my way through the Google Play Store’s rather complicated publishing process. Hopefully, it will be out soon so other families can use it too.
If you’re a C# developer who has never built a mobile app, give it a try. You might be closer than you think.
