Key Takeaways
- Xamarin Community Toolkit support will follow the same support timeline as Xamarin.Forms
- The Xamarin Community Toolkit .NET MAUI Compat version will have everything the XCT has and is compatible with .NET MAUI
- We can share code where possible, we can have .NET MAUI and Windows-specific code where needed and there is room to extend the CommunityToolkit family in the future with... CommunityToolkit.Blazor? CommunityToolkit.WinForms? Who knows!
- Essentials have nothing that shows any UI. Not any UI of their own at least. If any UI is shown that is coming from the OS it is running on. Essentials is all about accessing sensors, media, and other features that are not UI-related.
- All new development will go into the .NET MAUI Community Toolkit.
The Xamarin Community Toolkit is a collection of reusable elements for mobile development with Xamarin.Forms, including animations, behaviors, converters, effects, and helpers. It simplifies and demonstrates common developer tasks when building iOS, Android, macOS, WPF, and Universal Windows Platform (UWP) apps using Xamarin.Forms. The Xamarin Community Toolkit is available as a Visual Studio NuGet package for new or existing Xamarin.Forms projects.
Since the Xamarin.Forms is evolving into .NET MAUI, the Xamarin Community Toolkit (XCT) is also preparing for the transition. In this Q&A, InfoQ decided to interview Gerald Versluis. He is a software engineer at Microsoft from the Netherlands. He is a Senior Software Engineer at Microsoft, and he is part of the core team involved in Xamarin Community Toolkit development and maintenance. In this interview, we will talk about XCT, MAUI transition, and their future roadmap.
InfoQ: What are the features you would like to see inside of XCT in the future?
Gerald Versluis: There are so many great controls and libraries out there, driven by the community, hidden gems, it would be great to add some of those to our little Toolkit. I think there is still a lot of room for improvement for Xamarin.Forms and .NET MAUI ecosystem looking at the control suite. A lot of people are asking for some kind of data grid or autosuggest control and other things as well. So we either look into creating those ourselves, or we can ask a maintainer of an existing library that is out there if they might want to work together with us and add it to the Toolkit.
This way everyone wins: the maintainer doesn't have to bear the burden of maintaining a library alone, less scattered libraries, it will be added to a library that is active, backed by Microsoft, and more well-known. Having that said; the third-party vendors are doing a great job with their control suites, it will be hard to ever match those, but they are usually paid so not for everyone. This way we have options and everyone gets to use the controls they want.
But why stop there? I think one of the great things about the Toolkit is that we also gathered a lot of the converters that people are using. If you've worked with Xamarin.Forms you probably know at least 1 converter that you need in every project. But instead of wrapping it in a library, it's too small for that, you copy and paste it over and over again. Maybe tweak it in one project and suddenly you have multiple versions floating around. By centralizing those in the Toolkit, we make maintaining it easier, you can just drop in this one library which is now your one-stop-shop for all things Xamarin.Forms. And we hope to continue that with .NET MAUI.
InfoQ: .NET MAUI Community Toolkit is introduced, but what are the future plans of the Xamarin Community Toolkit?
Versluis: Everything we are doing in the Xamarin Community Toolkit (XCT) is something we need to (re)evaluate for the .NET MAUI Community (MCT) Toolkit. Because we are moving closer and closer to the release of .NET MAUI we will become more hesitant to introduce new features.
We roughly follow the same path for both Xamarin.Forms as well as .NET MAUI. The XCT, like Forms, will mostly receive bug fixes and minor service improvements at this time. At the same time, we are making plans for the MCT to see which features we would like to bring over and which features we might leave behind.
Effectively this means that we will make sure that the XCT will keep working with Xamarin.Forms and the new iOS, Android, and UWP versions are coming out, but no new features will be added. When the support for Forms ends, the support for the XCT will also end.
Going back to features we might leave behind for the MCT, worry not! We also have a .NET MAUI Compat (short for compatible) version of the XCT. If you know a little about .NET MAUI by now, you know that you can still enable a compatibility layer so that your Xamarin.Forms renderers and such can still be used in .NET MAUI until you have time to rewrite them to the new architecture.
The XCT .NET MAUI Compat version will have everything the XCT has but is compatible with .NET MAUI. So we have solutions for each scenario and you will never have to miss out on any functionality that you might use today.
InfoQ: Currently, there are a couple of Community Toolkits, do you think those should become one?
Versluis: With the move to the .NET MAUI Community Toolkit, we are actually, kind of, becoming one. The most notable other toolkit is the Windows Community Toolkit. We have been in close contact with them from the start of the Xamarin Community Toolkit but back then it was harder to combine our efforts.
Now, with a rewrite of the Toolkit from the ground up, we had the unique opportunity to work with the Windows Community Toolkit to work closer together. This means we get a unified name: CommunityToolkit.Maui and CommunityToolkit.Windows, we share a GitHub organization where all our code lives and wherever we can we will share code to not repeat ourselves.
Will they ever become one big library? I don't think so. Not more than what I just described. For this, I think it's good to have an understanding of what the different software development kits (SDKs) are and how they fit together. The Windows Community Toolkit (WCT) targets UWP, or rather Windows. .NET MAUI targets UWP, but also iOS, Android, macOS, and more. So, in terms of controls, for instance, it would mean that we have to match every control that is now in the WCT. And they already have a lot of controls, but also a lot of controls that work very well on desktop but less so on mobile.
Apart from controls the WCT also took MvvmLight and made their own evolution of that in the CommunityToolkit.Mvvm, which is great! Since Windows and .NET MAUI share a lot of the same concepts through XAML, we can now share that MVVM framework across our two Toolkits. And while doing so we can remove some concepts from our Toolkit that were bordering on implementing an MVVM framework ourselves, something we don't want to do. Now we can take our ObservableCollection improvements and other things out of our Toolkit, into the CommunityToolkit.Mvvm package. This way people who are not interested in MVVM won't get code they don't use, but still can add it very easily.
One big library also has a big disadvantage in terms of dependencies. Especially on Android, different controls live in different Android packages. Having everything in one library would mean that people get a big number of dependencies that they will probably never use. This is a fine line we try to balance already with the XCT and MCT.
The way we organized it now allows us to really mix and match. We can share code where possible, we can have .NET MAUI and Windows-specific code where needed and there is room to extend the CommunityToolkit family in the future with... CommunityToolkit.Blazor? CommunityToolkit.WinForms? Who knows!
InfoQ: MAUI Essentials is introduced, Are there known strategies which features will go into Community Toolkit and which one to Essentials?
Versluis: We don't have any official agreements or guidelines on this. But looking at what is in Essentials and what is in the Toolkit the separation is kind of clear. It all starts with: the Toolkit has a hard dependency on Xamarin.Forms, Essentials doesn't. You can use all the Essentials APIs on a Xamarin.Android or Xamarin.iOS project if that's what you want. It's basically an abstraction layer over the native APIs to make them more .NET style.
The other thing is: the Toolkit has a lot of UI features. Whether that is supporting functionality for working with XAML or complete now controls. Essentials have nothing that shows any UI. Not any UI of their own at least. If any UI is shown that is coming from the OS it is running on. Essentials is all about accessing sensors, media, and other features that are not UI-related.
There is always a grey area where there is some overlap, but the teams of Essentials, .NET MAUI, and the Toolkit are pretty close to each other so we can sort things out really quick and easy.
InfoQ: Regarding the future, will all features that are implemented in the .NET MAUI Community Toolkit also be implemented in the Xamarin Community Toolkit?
Versluis: If you mean if we have plans to backport new functionality from the MCT to the XCT the answer will be pretty simple: that won't happen. As already mentioned; we will follow the same path with the XCT as Xamarin.Forms. "Real" development stopped, we're now focussing on fixing bugs and maintenance to keep the XCT compatible with Xamarin.Forms and the OS targets they are running on so you can enjoy it as long as possible, but nothing new will be added.
All new development will go into the .NET MAUI Community Toolkit.
About the Interviewee
Gerald Versluis is a software engineer at Microsoft for the Xamarin.Forms/.NET MAUI team. After years of experience working with Azure, ASP.NET, DevOps, Xamarin and other .NET technologies, he has been involved in a number of different projects and has been building several real-world apps and solutions. Not only does he like to code, but he is also passionate about spreading his knowledge – as well as gaining some in the bargain. Gerald involves himself in speaking, providing (video) training sessions and writing blogs and articles, answering questions on Stack Overflow and contributing to open-source projects in his spare time.