.NET MAUI Developers Struggled With iOS App Size and Android Booting – Visual Studio Magazine


.NET MAUI developers struggled with iOS app size and Android startup

Microsoft has struggled to improve the performance of .NET MAUI beyond that of Xamarin.Forms, struggling with thorny issues such as iOS app sizes and Android startup times.

According to a long and painstakingly detailed blog post on these difficulties, it worked for .NET MAUI (.NET Multi-application UI), which just achieved general availability status on its way to replacing Xamarin.Forms, including the ability to create desktop apps in addition to mobile apps.

“Our goal was for .NET MAUI to be faster than its predecessor, Xamarin.Forms, and it was clear that we had work to do in .NET MAUI itself,” said Jonathan Peppers, Senior Software Engineer, in a gargantuan June 7 post titled “Performance Improvements in .NET MAUI”.

He said the team is convinced that gains in developer productivity should not come at the expense of application performance.

“The same could be said about app size – how much overhead is there in a pristine .NET MAUI app? When we started optimizing .NET MAUI, it was clear that iOS had some work to do. to improve app size, while Android lacked startup performance,” he continued.

To strike a balance between application size and startup performance, the team solved a dizzying array of issues with numerous tests and tweaks that refined aspects ranging from different types of early builds (AOTs) to loading lazy to color-optimized parsing dependency injection and hundreds of others.

Take AOT, for example, a big sticking point in the .NET world, as the lack of officially supported native AOT has actually driven developers away from the framework, according to a 2020 Microsoft survey.

AOT has proven to be faster than just-in-time (JIT) compilation because the latter happens the first time every C# method is called and therefore implicitly impacts startup performance, which is a major concern in mobile apps. However, AOT increases the size of the application, because, for example, an Android native library is added in the final application for each .NET assembly, which increases the amount of code to load. This conundrum required a balanced compromise, a compromise that prevails in software development.

“To give the best of both worlds, boot tracing or profiled AOT is a current feature of Xamarin.Android,” Peppers said. “This is a mechanism for AOT’ing the startup path of apps, which dramatically improves launch times with only a modest increase in app size.

“It made perfect sense for this to be the default option for Release builds in .NET 6. In the past, the Android NDK was required (a multi-gigabyte download) to do AOT of any kind with Xamarin.Android We’ve done the legwork to build AOT apps without an Android NDK installed, allowing it to be the default in the future.”

Thanks to this and many other optimizations, the team has indeed reduced boot times, as evidenced by the two graphs below, the first showing the test results for Android boot times in the first few previews, while the second shows performance improvements “after the dust has settled.”

Android boot time in early previews
[Click on image for larger view.] Android boot time in early previews (source: Microsoft).
Android boot time after optimizations
[Click on image for larger view.] Android boot time after optimizations (source: Microsoft).

“Getting to where we are today was a collaboration of several different teams,” Peppers said. “We have improved areas such as the use of Microsoft.Extensions and DependencyInjection, AOT compilation, Java interoperability, XAML, code in .NET MAUI in general, and many more.”

While several developers praised the team’s efforts in the comments section of the blog post, one was the exception, saying that the performance improvements are secondary to larger concerns such as features and missing features.

“Currently, there are many cases where an API on a platform only does [is] documented as working,” the comment said. “Most importantly, API Essentials. For example, taking pictures on Windows does nothing. Processing images using Maui.Graphics on Windows does nothing as they cannot be loaded as an IImage (not fully implemented)! How can this be a full version? How can you post a feature that doesn’t work? By looking at the publicly available source code and only seeing some parts implemented? I don’t understand this behavior with MAUI.”

About the Author

David Ramel is an editor and writer for Converge360.

Comments are closed.