Navigation

.NET MAUI Evaluation

By on April 19, 2022 in .NET, Code Quality, iOS Development

Introduction

In this article, I’m going to summarize my evaluation for .NET MAUI for use as frontend technology. This evaluation was done with Preview 14 and Release Candidate 1 versions. My apps have 95% of the code outside of the frontend project, with the frontend hooked up to events and commands. With an application designed this way, the benefit of MAUI would be to have the capability of developing for a desktop system and then move the whole application to other platforms without the need to rethinkthe UI layout.
The additional benefit for being able to use a desktop targeting while development and switching to mobile targeting at the latest possible time, before installing on mobile, would be that I can get rid of the problematic IDEs on macOS:

  • Rider, regularly thinks about what actions are available during the development, ranging from 5 seconds to minutes hang up of the IDE during debug sessions and around leaving the debug session. See this bug: https://youtrack.jetbrains.com/issue/RIDER-75023/Rider-is-regularly-thinking-about-reacting-to-tab,-why-typing-in. This issue is constant regression, has been reported multiple times.
  • Visual Studio for Mac, beside it is a reskinned version of the Xamarin Studio, which was a reskinned version of Mono Develop, which was never a capable IDE, the 2019 version has a bug somewhere that causes my solution composed of 12 projects to load for 30 minutes at least when opening. To be fair, the problem has been fixed in preview versions of 2022, but it is not yet released. Just Visual Studio for Mac is really feature incomplete, when compared to Visual Studio (the Windows, fully featured IDE).

As a result, if Windows system can be targeted during the development, I could use Visual Studio for development and then build the applications on a mac with a build pipeline. Current Visual Studio environment has integrations with a mac for building Xamarin applications, but that is also cumbersome at least, buggy most of the time.

Goals

Keeping the information in the previous section in mind, the goal of my investigation was to get the following target environments working for the same codebase:

  • Windows
  • macOS
  • iOS (simulator, device)
  • Android (simulator, device)
  • Linux (Blazor – more on this later).

Preparation

As a starting point, I’ve used
https://docs.microsoft.com/en-us/dotnet/maui/get-started/first-app:

  • I’ve installed Visual Studio 2022 17.2 (Preview) version
  • I’ve installed Mobile development .NET workload.
    • Here, I’ve run into my first problem. Since I’ve already had the workload previously installed with an earlier version, I was missing the project templates. Removing the workload and installing it again helped.

Windows desktop target (Preview Version 14)

After generating a MAUI application with the project template, I’ve tried to compile it for Windows environment and run it. Problems:

  • I got an error complaining about the fact that there is a need for recipe. I got over this by switching to Android target and then back to Windows target.
  • Developer Mode was not enabled on my Windows desktop. This is just an annoying thing of the operating systems, Visual Studio was kind to point in the right direction for flipping the switch.

The application started up correctly, and I was able to click the button in the usual “Click Me” example. I’ve compressed the codebase and moved it over to my Mac.

macOS (Preview Version 14)

After uncompressing the code from the Windows system, the first thing I wanted to try was to run the code on macOS.

I’ve verified the version of the dotnet tooling by typing:

dotnet --version

The result was 6.0.202, which was the expected as the required version. I’ve issued the command:

dotnet build -t:Run -f net6.0-maccatalyst

in the solution directory, and it turned out that the generated codebase from the template on the Windows system was missing something to be able to compile it on macOS. Generating a new example application on the Mac was resulted in a codebase to be able to compile. Probably there is a way to merge the two templates later. To generate the example on macOS, type:

dotnet new maui -n "Example"

iOS Simulator (Preview Version 14)

To get the UUID/UDID of the simulator, to use:

  • Start Xcode, the go to the simulators (Window > Devices and Simulators)
  • Right click on the simulator
  • Select “Copy Identifier”

To build for the simulator, execute the following command:

dotnet build -t:Run -f net6.0-ios -p:_DeviceName=:v2:udid=<Insert UDID here>

Started properly. So far, three environments, some small issues, but got three environments working. Not bad.

iOS Device (Preview Version 14)

Here, no matter what I’ve tried, I couldn’t get the example up and running on the device. I’ve tried:

  • Connecting the device to the Windows system and using, Local iOS: Had issues with Hot Reload
  • Connecting to the device via mac build agent: Got complaints that the feature requires at least Xcode 7.3 – I had 13.x, so maybe (probably Apple) should check that message for accuracy.
  • Building the application in Visual Studio 2022 for Mac preview. At this point I’ve realized that Xcode itself is having trouble setting up my iPhone for development. This triggered a full operating system upgrade, since the newest Xcode is not installable on Big Sur, just on Monterey.

Since I couldn’t get the iOS device working with Preview Version 14, this is where I ended my experiment with this version as iOS is my main development target. I’ve found a few interesting links during this part:

Release Candidate 1

Hurray, the countdown for the GA version started. One month, according to the timetable at the time of writing, and GA is released.

Since the time I’ve stopped with Preview Version 14, I’ve upgraded my macOS, which resulted in troubles with python 2.7 removed, rendering gitosis unworking, so I had to build a docker container for my git repository system. On the other hand, Xcode now recognizes my iPhone again. Apple should really stop shipping minor version upgrade requiring full operating system updates on the development side. It turned out that the issue triggering everything to be upgraded was iOS 15.4 being installed on the phone. These upgrade forcing changes should really be major version upgrades.

Back to iOS (Device)

Visual Studio 2022 for Mac Preview still had a few issues with compiling for the iPhone:

  • While compiling for iOS device, it was complaining about Android. At least, compared to Preview Version 14 time, now I got an actionable, meaningful error message. Installing the missing workload helped: 
    dotnet workload install maui-android
  • The template (generated with Preview Version 14) had a missing target for the iOS device. I haven’t checked if the RC1 template has the same issue. Manually adding the build information helped:
  • In the project file the OutputType for the MAUI main project should be Exe instead of Library, otherwise the application is not starting on the device:

Android

At this stage, both Android emulator and the device were presenting no additional problems.

Linux (Blazor WebASM)

I was expecting that the same UI technology maybe could be used for generating WebASM code, but it turns out that is not the case. On the other hand, as mentioned in the introduction, my application is mostly in platform independent libraries, so adding a Blazor frontend to it won’t be too much of a problem. Built an example container for WebASM: Gist: https://gist.github.com/atzimler/41b605d1f16c5556fad22983d6df2712

Let’s port the Application

Well, the template for MAUI is broken in RC1, just differently. It is unable to launch the Windows application. The template from Preview Version 14 is still working. I had to leave the computer for a while, so I’ve switched the PC off. When I returned I’ve restarted the port on macOS. Probably because my Mac is faster to wake up.
I’ve started to build out the UI of the application by replacing the MainPage of the example application with a minimalistic MainPage resulting from copying the class from the Xamarin Forms code and commenting out everything that does not compile – at this stage everything except the class skeleton. This succeeded.
As a next step, I’ve installed the Syncfusion MAUI controls, which was relatively easy, and set up the tabs. Beside seeing the result on macOS, I was interested if it would look properly on Android – given that is one main issue that I had with the Xamarin Forms system. It worked correctly, according to positive expectations.
I’ve added a button onto it to print out the width and height of the MainPage, so that I can set my macOS window to the appropriate size, testing the purpose of the development environment. Grabbing the information went well. Setting the window size on macOS not so much.
It turns out that there is no way to properly set the window size in a platform independent way neither on Windows nor on macOS. On Windows you can Pinvoke into the system to set the window size, but that doesn’t work on macOS, obviously. A PInvoke trick should not be present in a portable application. I couldn’t find any solution for resizing the window on macOS.
Links:

Conclusion

At this stage, with the window not being resizable, I cannot achieve the development environment with MAUI as planned. I will keep an eye on the tickets listing the resize problem, however, since my application is mostly UI independent, changing the UI system is not a benefit if the change does not deliver platform unification of the UI code.

NOTE: I know this is somewhat badly formatted. I’m having trouble to actually getting the only one functionality (publishing) working properly in WordPress. Such are Today’s software package qualities, sadly. The one functionality it is supposed to be designed to, is the functionality that does not work.

No comments yet.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by WordPress. Designed by WooThemes