Multi-platform App UI
MAUI stands for 🎬
M
ulti-platform
A
pp
UI
🎬
It is a framework over dotnet to build apps with UI.
Last updated: 2024-05-06
For C# developers, it's an edge technology by Microsoft for building multiple apps having an UI with the same codebase. Honestly with Maui - today - you essentially build mobile apps.
When building a mobile app with Maui, the developer create 95% of the app with the same code for both Android and iOS. The 5% are specific UI adjustements for the feeling that users are used to on each platform.
Maui supports creating:
- Native mobile apps (including tablets), on iOS and Android platforms.
- Native desktop apps: on Windows and Mac platforms. Maui is replacing the old WPF technology.
- Native samsung apps: on Tizen based smart TVs
The word native is important. It’s the main distinction between that technology and other html/javascript based technologies like react native.
Other apps that can be created with C# but don’t need Maui, only dotnet, are for example:
- console apps: Windows, Mac, and Linux (adm64, and arm64 like Raspberry Pi)
- server apps: mostly web API.
On Linux, dotnet server apps run so fast ! It is my 1st choice when it comes to stability and speed.
What are MAUI apps
Maui apps uses native UI bricks. Native means the UI bricks created by Apple (for iOS) or Google (for Android) or Microsoft (for Windows). That gives the app a fast and fluid look and feel, different on each platform but well integrated into that platform.
Both Maui and net8 are open source under the MIT license, which means you can do whatever you want with them, including resell them if you dare to. The source codes are on github.
Maui apps are compiled. That mean they are fast
Maui apps are compiled. That mean they are fast. Even if the development flow is not as smooth as other tools. For exemple the developer have to rebuild and re-deploy its whole app after making a change to the code, expect the UI code: Maui apps do support live update of the UI (xaml) during development.
For those who knows Xamarin, Maui replaces Xamarin while being faster and modern. It is based on the dotnet core engine - version 8 at the time of writing - while Xamarin is based on the very old “.net 4” engine. The support of Xamarin by Microsoft has ended. Its github repository is now archived and read-only.
Coming to alternatives to Maui, there is only one that is worth writing about. It’s called React Native. It is tailored for javascript developers using the React framework. The UI is entirely rewriten in React’s HTML-like components. React is also open source and backed by Meta (facebook). The main advantages of React are to reuse the skills of the HTML/js team, and the live update of the app while developing it. Behind the shiny description, it also has issues. Live update can stop working suddenly. And you can scratch your head getting your UI looks as you need it.
No matter which technology path you opt for, having proficient developers is crucial. Mobile development presents its challenges. You can either opt for inexpensive developers, resulting in a two-year journey to build an app that hardly resemble your vision - draining your energy along the way. Alternatively, investing in highly skilled developers can yield to a polished app within a few months, giving you a competitive edge in the market 📈. Feel free to reach out to me if you are interested in the latter solution, I’ll be happy to share our portfolio with you.
Ecosystem
Maui already have a strong ecosystem. The UI technology is almost 3 years old already. The root technology on which Maui is based - ”dotnet core” - is already 6 years old and has proven to be stable and evolutive at a fast pace.
Vendors have embraced Maui and published many components. Among them:
- Telerik
- Grial
- Devexpress
The Maui project itself is very active. Take a look at the activity on ONE month only:
The release pace is one new minor release of Maui per month.
There is one little embarassing thing: how major releases are paced. There is one major release per year, every october. Nothing fancy. But what’s embarassing is, that major release is based on the next version of dotnet - which means you can’t publish an app with that version - and is started 9 months before, in march. That’s ok, except when it comes to some major bug fixes, when those bugs are fixed only in that preview version and never in the stable version. It happened last year, hopefully it won’t happen this year.
Customers won’t be impacted though, as the developers know how to workaround any limitations of code they can’t change. That is part of their everyday work, at least mine.
Installing MAUI
The maui toolset includes dotnet8 SDK (Software Development Kit), maui SDK, and official SDKs for your targets: Android, iOS/MacOS or/and Windows.
A SDK is a set of tools and files required to create a software for a specific target using a specific technology.
- Install
- For Android you will need the Android SDK. Get it by installing Android Studio. Get Android Studio by usingso it updates automatically. You will also need(Java JDK 21 is incompatible with Android SDK at the time of writing).
- For iOS you will need a Mac and xcode. Get xcode from the Mac App Store. To be able to install the latest version of xcode (required v15 at the time of writing) you must use the latest version of MacOs. Make sure your Mac is up to date !
Then open a command line and run:
dotnet workload install maui
Choosing an IDE
Coding using the command line is possible
but is highly inefficient nowdays.
Maui is supported by those 3
Integrated Development Environment
tools today:
- Visual Sudio Code: for the poors
- JetBrain’s Rider: for the pro.
- Visual Studio Windows: only for Android, Linux and Windows apps. I was never able to build for iOS reliably from VS Windows using the remote build to Mac feature, even using Rider which also has that feature.
Note: Visual Studio Mac does not support Maui.
Conclusion: the must have tool is Rider.
If you still want to go the Visual Studio Code path, put a cross on the live UI update for now.
Warming up 👣
1st get a list of template projects to start with, or use your IDE to create a new project.
For most apps, that’s all. Run the app and start coding !
For iOS app on devices you will need to register both an account and your devices with Apple first. A 100$ fee is required every year per developer account. Your enterprise can create an entreprise developer account and pay a higher fee for all its developers.
Coding the app itself requires multiple skills.
To be efficient, use auto scaling vector images (SVG format) for all images and icons. For that I recommend
which makes so easy to use SVGs with no pain.
For local data storage, choose between
and
(for new projects Realm is very cool). For data mapping, forget automapper, use
.
After having created your beautiful app, you have to distribute it. It’s often a pain for developers. Let’s see how that can be done in the next chapter.
Distribution (Build &, CI/CD)
This chapter describes how to automate distribution of release versions of your app (opposed to debug versions that developers use). It does not describe how to setup your app in the stores. There are many requirements there, including media with
and specific app metadata.
Whatever tool you will choose, the first distribution must be done entirely manually. This is a store requirement from Google and Apple.
Stores are a great place for marketing. They are as important as your website, if not more. You have to follow
any user commenting on your app. Especially angry users that vote 1 or 2 stars, and drive you app’s rating down.
Build and distribute using
That’s the best solution. Codemagic build machines are M1 (free) and M2 macs. Their Mac image contains all required tools including multiple xcode versions. They are very fast to add new xcode versions, including beta versions.
They have a very clever shell tool that retrieve the latest build number used for an app on Apple App Store and Google Play Store. No need to store the build number to increment it. No more headaches when the CI script is mixed with custom build steps.
The total build time for a maui Android or iOS app is around 10mn per app.
The pipeline is configured by a unique codemagic.yaml file that must be at the root of the git repository. It contains a list of jobs. A job can be triggered by tags, branches, api and manually.
A caching feature can cache up to 1GB of data between builds. For maui I did not find where to use it efficiently, even the nuget cache folder for a build is over 1GB (on my development machine it’s over 50GB !)
Distribute using Azure Pipeline
I don’t promote this solution, as the documentation is very light and not targeted on maui.
Also, after the Ms AppCenter retirement, I don’t trust that Ms product anymore. Some points tick my mind, like the doc which is very lightweight (with no mention of maui at all).
For me that means there is no will of pushing forward more this product, which means no more investment, which means it’s in maintenance mode, which is a promise of low speed updates along with bugs and sweat for users. I skip my turn.
If you still want to go that uncertain way, those extensions might be helpful:
,
. For the Apple extension, the “Key content” field must be the full original content of the p8 file encoded in base64.
After your app is distributed, it has a life. You must fix the issues that arise because of your own bugs of course, but also because of Apple/Google/Windows software updates or because of new devices not behaving like older ones.
There are other reason like customer voices requiring easier or new features, and of course your business goals. But it’s not the discussion here.
Let’s see how this can be done in the next chapter.
Crashes and Insights
Apps run by customers may crash. You have to find a way to notify both you and your developers that happens. Your customers may not give any feedback and trash your app.
Instead you can instrument your app with an insight tool. In this chapter I’m offering you the best tool I know of: Sentry.
is the must have tool to get crash reports.
Sentry displays crash logs as readable (symbolicated) C# crash logs. It groups them so you are not flooded with the same logs. It automatically logs important device informations so you know excatly the scope of a crash.
Sentry also logs a breadcrumb that lead to a crash ! That breadcrumb includes what flow of pages appeared or disappeared before the crash happened. This is very useful to reproduce and crush crashes.
Sentry can also get and display logs that the app is posting using standard Microsoft ILogging. You get the important logs remotely !
To add sentry to a maui app, add
.UseSentry(...)
to the app’s builder, specifying your Sentry access key. Thats all !
To be GDPR compliant (required for apps distributed in the EU and Brazil), your app should collect user’s consent to send (crash) logs.
Conclusion
Building a mobile app requires multiple skills. Maui helps by sharing your codebase between different OS by 95%. But that still requires highly skilled developers.
Your mobile app has a life. You have to invest on it on a regular basis. By answering your users (including the store’s comments), following changes in trends and OS versions, fixing issues and making changes to match your user’s requests or your business targets.
If security is important for you, you’ll have to update your app at least once per month.