At Great Ideaz, we recently had to address this question from the perspective of “how do we want to invest our development resources?“
We spent the last couple of years building a very complex .NET Blazor-based User Experience for WASM Clients into our trellispark platform. The trellispark codebase is compiled as a set of Blazor components in a class library that can be composed with an Authentication Web project to deploy as a WASM client. The primary feature of the trellispark UX components is to render any custom user experience at runtime, eliminating the need for creating custom pages.
As you can imagine, re-creating the trellispark user experience using a Native MAUI project would be a significant investment.
We started by building a MAUI Authentication project and then incorporating our Blazor user experience with a BlazorWebView component. This took hardly any time at all and immediately gave us a viable MAUI Blazor Hybrid solution.
The main reason for using Native MAUI is that we could target older devices running older software. Since most device manufacturers recommend regularly updating device OS versions to apply security patches, we questioned the market exposure to support backwards compatibility of Native MAUI compared with Blazor on mobile devices. The chart below summarizes version compatibility of .NET MAUI and .NET MAUI Blazor compared with worldwide market share (compliments of gs.statcounter.com). We concluded that the additional backwards compatibility coverage of market share was very low (and shrinking).
| OS | .NET MAUI Blazor | OS version Market Coverage | .NET MAUI | Market Coverage Gain |
|---|---|---|---|---|
| Android | 7.0 (API 24) or higher | 91% | 5.0 (API 21) or higher | Less than 1% |
| iOS | 14 or higher | 82.4% | 10 or higher | Between 2.7 to 15% |
Native MAUI provides a wrapper around the lowest common denominator native device user experience controls and the range of controls is limited compared to Blazor. This was evaluated as a negative value as it would actually reduce the functionality available in the overall user experience.
For us, an advantage of using MAUI Blazor Hybrid is that we can still use the rich Blazor user experience components we initially developed for web applications. This means that we can keep the same basic user experience across all platforms – we are just composing our Blazor project with a MAUI Authentication project.
We did want to take full advantage of the capabilities of the device running the trellispark platform. We found that MAUI Essentials exposes all the device functionality in a form that can also be included in our Blazor component project (learn how to add MAUI Essentials to your Blazor project in this blog post). By adding an Interface over the MAUI Essentials we can use the device capabilities when in the MAUI Hybrid, and then gracefully degrade when in the WASM client.
For the MAUI Hybrid, the user experience is being compiled and the performance is quite acceptable. We may get a slight improvement using MAUI Native instead of MAUI Hybrid but in reality most users probably wouldn’t notice the difference. The key performance bottleneck for us was the round trip time to the API through which we access the data storage,
Conclusion
For us the answer was easy, we decided to focus on a MAUI Blazor Hybrid approach because we determined that the best use of our investment was integrating MAUI Essentials into our Blazor components. That way, we could get the best consistent user experience from the Blazor components without sacrificing the device capabilities.
Would we look at using MAUI Native in the future? Perhaps, but for now we are thrilled with MAUI Blazor!
What has your team decided? Add your comments to this post ⬇ 🙏
We would like to thank the Visual Studio, MAUI and Blazor teams – they have done a fantastic job of developing an awesome set of tools that have been a huge improvement to our trellispark platform!