- .NET MAUI (.NET Multi-platform App UI) will bring a lot of consistency to the developer experience, and enables some new, innovative experiences for developers
- Some of the main goals of .NET MAUI are about modernizing the design capabilities, and extending from mobile to desktop platforms starting with Windows and macOS
- Single project is a solution to align more closely with this developer focus while still providing all the native platform access important for delivering truly native experiences and it will be the default experience for new projects.
- The migration from Xamarin.Forms to .NET MAUI will be well defined, and the development team will try to make it smooth as possible.
- .NET MAUI will bring a lot of options to choose from and to decide what is best way for developers to design and develop their apps
.NET MAUI is an evolution of the Xamarin.Forms toolkit, aimed at improving app performance and simplifying multi-platform app development. The framework will provide a single codebase with built-in resources to access the native API for all modern operating systems (Android, iOS, macOS, Windows). Developers will be able to develop multi-platform applications under a single project structure, adding different resources or source code files for different platforms when necessary.
With all this great plan on the roadmap, InfoQ decided to interview David Ortinau, currently principal program manager for Mobile Developer Tools at Microsoft focused on Xamarin.Forms and now on .NET MAUI – to talk about .NET MAUI, the goals behind it, it’s future, and the migration path from Xamarin.Forms.
InfoQ: What is the .NET MAUI project and what are the main goals behind it?
David Ortinau: It all begins with unification. We are moving our client application development to .NET 6 from .NET Framework, using the same base class library (BCL) as other application types, and modernizing our project system to align with the rest of .NET. Today Xamarin projects use what I call a “frankenproj” which is a series of workarounds that are legacy from when Xamarin wasn’t yet part of Microsoft. This will bring a lot of consistency to the developer experience, and enables some new, innovative experiences for developers in .NET MAUI.
Our goals are driven by our customers. We spend a huge amount of time learning from companies and developers about how we can help them achieve more success. To that end we are investing focused effort to improve overall quality of the product, and application performance and size. These two are ongoing goals, and we are already seeing positive signs in our ad hoc benchmarks that .NET MAUI will be a nice step forward from Xamarin.Forms.
Our other two goals are about modernizing the design capabilities, and extending from mobile to desktop platforms starting with Windows and macOS. When Xamarin.Forms was created over seven years ago, the market trend was to deliver a platform-specific look and feel for your apps. Over time this trend has moved towards delivering a more consistent design for the app no matter where it runs. .NET MAUI is making controls easier to customize, and adopting a unified default design that is more aligned to your goals.
InfoQ: Currently Microsoft and community support for Xamarin.Forms are great! But, what will happen with Xamarin.Essentials and all of those great third-party libraries which we use today in Xamarin.Forms projects?
Ortinau: Xamarin.Essentials has proven to be so fundamental that it has been merged into .NET MAUI. No matter what kind of client application you are developing, you have everything you need at your fingertips. The code is designed to be linker safe, so your application only compiles the features you use in your app.
All active libraries in the ecosystem should migrate to .NET 6. Those that have already adopted .NET Standard should find this to be a similarly simple upgrade. Libraries that implement Xamarin.Forms UI will have a bit more work to do when they depend on Xamarin.Forms types. We are currently navigating this transition in our own codebase where we have introduced a compatibility namespace for bringing forward Xamarin.Forms code that hasn’t yet been ported to our new handler control pattern. As we port controls then .NET MAUI benefits from the improvements and the compatibility controls are no longer needed. So, what I’m trying to show is that there’s a continuum of change that UI library maintainers can travel from basic compatibility to fully ported.
We have talked to commercial component vendors eager to make this transition to continue serving their customers. If you use one of these, please let them know of your interest in seeing .NET MAUI support from day one.
We have a monthly call that is welcome to anyone where we have open dialogue between our engineering team and library maintainers. This is all about helping the ecosystem make this transition successfully. We are in this together!
InfoQ: There are many competitors currently developing different alternatives to .NET MAUI. What is your opinion about this situation?
Ortinau: I reject the framing that within the .NET ecosystem this is a battle and a competition. One of the great things about being open source is the ecosystem can grow many options for developers. Uno offers a development experience that is extremely familiar to Windows developers, and uses Xamarin. Similarly, WPF developers can feel very at home and productive with Avalonia. Having options such as those in the .NET ecosystem means .NET MAUI is empowered to address other needs of .NET customers.
InfoQ: If we are beginning a new project today, should we go with Xamarin.Forms or wait for .NET MAUI?
Ortinau: Use Xamarin.Forms, without hesitation! The migration to .NET MAUI will be well defined, and we are taking care to make it as smooth as possible.
Now, once we get to the middle of 2021 you may wish to consider starting with .NET MAUI instead. Keep an eye on the .NET blog for news about the progress with .NET MAUI to determine if enough of the pieces are there for your application needs to begin using it. In addition to how many of the controls and layouts have been ported, look for essential productivity tooling for things like hot reload, hot restart, and multi-targeting for single project experiences.
Of course, I encourage everyone to dip your toes into the .NET MAUI waters throughout the previews, and please share your interest and feedback to our team on GitHub.
InfoQ: Last year, there were a couple of Blazor mobile bindings mentioning .NET MAUI, and some of the last .NET Conf sessions involved Blazor and MAUI desktop scenarios. What is the role of .NET MAUI in the whole Blazor context?
Ortinau: In .NET 6 we are shipping Blazor hybrid experiences for desktop. This means you can use Blazor web components to build app experiences that also have seamless access to native device services necessary for delivering desktop features, such as online/offline, file system, location, notifications, and much more. This is made possible by building upon the .NET MAUI toolkit and shipping the first control from the mobile bindings experiment, the BlazorWebView. You have full access to all the desktop controls and APIs from .NET MAUI in addition to the HTML and CSS a Blazor web developer is already using today.
Because it’s all .NET code, there is no bridging back and forth between the Blazor context and .NET MAUI. It really is seamless!
InfoQ: Microsoft recently released the .NET Upgrade Assistant. Are there any plans for a similar tool related to .NET MAUI and Xamarin.Forms, or something to set a smooth migration path?
Ortinau: Absolutely! Now that the .NET MAUI design is beginning to stabilize, we have a more solid idea of what the migration work will need to look like. Look for more details about this mid-year.
InfoQ: The most exciting thing about .NET MAUI is the single-project experience. What is the motivation behind it, what are the problems the single project is solving?
Ortinau: Xamarin was born in a world of bringing 1:1 native mobile development to .NET developers. It was also done outside of Microsoft during a period when not everything was open source, and the result was a solution with multiple app projects with specific build requirements plus shared library projects for business logic. This has been an accepted complexity for years.
We interview developers all the time, both within our ecosystem and those with zero .NET experience. Common things we hear are that managing platform specifics (think images, fonts, etc.) is a hassle, managing NuGets across multiple projects is confusing, and the multiplicity of projects in the solution just doesn’t match how developers think about their applications. Developers think first about a single application experience, and occasionally about platform specific scenarios.
So, “single project” is a solution to align more closely with this developer focus while still providing all the native platform access important for delivering truly native experiences.
Many aspects of what we call “single project” will be available to everyone using .NET MAUI, regardless of whether or not you choose to reduce multiple projects down to a single one. For example, you will be able to leverage the library project to manage images, fonts, resources, and to multi-target code per platform. Those features can be adopted ad hoc as they are beneficial to your applications.
Single project will be the default experience for new projects. For existing projects I recommend you adopt the aspects of this experience that you want first, and then think carefully about whether you should go all the way and reorganize your solution.
InfoQ: A good part of the community would appreciate VS Code support. Is there any plan to provide that kind of support for .NET MAUI development?
Ortinau: This is not on our roadmap to bring official support for .NET MAUI to Visual Studio Code, but that doesn’t mean we don’t have good news for you! The Comet experiment focuses on how .NET MAUI would look to a developer who prefers the Model-View-Update pattern over MVVM, C# over XAML, and VS Code over Visual Studio. Because Comet is .NET 6 and is based on .NET MAUI, it also works for .NET MAUI apps that don’t use MVU (yay .NET!). You won’t get amazing XAML IntelliSense and much else, but it’s a great start that supports .NET 6 previews, single project, device selection, and debugging. Check out the April 2021 Xamarin Community Standup on YouTube with Jonathan Peppers if you would like to see this in action.
If you’re interested in seeing VS Code get official support, please engage with the Comet project.
About the Interviewee
David Ortinau is a principal program manager for Mobile Developer Tools at Microsoft, focused on Xamarin.Forms. A .NET developer since 2002, and versed in a range of programming languages, Ortinau has developed web, environmental, and mobile experiences for a wide variety of industries. After several successes with tech startups and running his own software company, Ortinau joined Microsoft to follow his passion: crafting tools that help developers create better app experiences. When not at a computer or with his family, Ortinau is running through the woods.