An oft-asked question to the .NET MAUI team whenever they talk about their cross-platform support is, “Well, what about Linux?”
Last Month, we announced our intentions to bring Linux and WebAssembly support to .NET MAUI through Avalonia. And with that, they could finally answer the question. As we build Avalonia-based handlers and controls for .NET MAUI, we are working closely with them on this initiative, collaborating to identify and contribute the necessary upstream changes to the official .NET MAUI repository, ensuring our work benefits the entire ecosystem, including other platform implementers.
We saw tons of excitement and significant questions about how we would make it happen and when we would release it. At .NET Conf China 2025, I spoke about how we would deliver this, how we have progressed over the past Month, the challenges we faced, and the challenges .NET MAUI would need to overcome to enable true interoperability with third-party application frameworks like ours. You can view the talk on Bilibili or YouTube, and here I will elaborate on the points I raised during the talk.
.NET MAUI Handlers and Layout
First, let's talk specifics about how .NET MAUI renders its controls.
The core design of .NET MAUI's controls is in the Handler architecture: a lightweight, performance-focused bridge between cross-platform controls and native platform views. For example, when you create a Button in .NET MAUI, it renders as a UIButton on iOS, a MaterialButton on Android, and a native button on Windows, all surfaced from the IButton interface.
With Avalonia, this becomes vastly simplified. We build a single set of handlers with Avalonia and map those controls to existing Avalonia versions, extending or creating new implementations as needed. These handlers can then be deployed to any platform Avalonia targets, allowing for more .NET MAUI in more places.
For the current version of .NET MAUI, we can integrate it relatively seamlessly, with some exceptions; the .NET MAUI Handlers, their core library interfaces, and infrastructure are enough to allow us to overwrite the underlying system base. So long as our target platform does not overlap with any specific platform that .NET MAUI already targets, like iOS or Android, we can swap out implementations wholesale and replace the entire body of the app with a drawn version.
As Avalonia includes a SkiaSharp-based renderer, we can also leverage the existing Microsoft.Maui.Graphics and SkiaSharp.Controls.Maui libraries. As they all share SkiaSharp and its version of Skia, we can wrap these handlers with underlying Avalonia-based controls. From what we have seen so far, it allows for a wholesale one-to-one mapping of many controls with minimal changes, operating exactly as they would within a general .NET MAUI app. For example, AlohaKit, created by Javier Suárez, who recently joined us from the .NET MAUI team at Microsoft, is an experimental .NET MAUI project for implementing drawing controls in Maui.Graphics APIs. We can take their gallery app and, once we apply our libraries and platform support, run it unchanged. We hope this will make it easier for those already using these libraries to draw their controls and add more platforms to deploy to.
.NET MAUI's layout system works similarly. It uses an ILayoutHandler interface to position controls directly on platform primitives: UIView on iOS, View on Android, and FrameworkElement on WinUI. Notably, .NET MAUI's own layout controls (such as StackPanel) don't simply wrap the platform's native equivalents; MAUI handles the layout calculations itself, and positions views directly.
Since .NET MAUI handles positioning and constraint calculations on its own, we let it do the calculations and position it precisely as it specifies, then pass it directly to Avalonia. Once we implemented the ILayoutManager and CrossPlatform Calculations, many of the standard layout controls in .NET MAUI "just worked," and worked exceptionally well.
ControlGallery
The ControlGallery app we released alongside our initial blog post was a proof-of-concept application to demonstrate we could port .NET MAUI infrastructure enough to get some apps and controls up and running. I made some of them quite hastily (you could even say "vibed." I'm looking at you ListView.), but the intent was for a cost estimate for this project and its overall viability.
With it, we established it would be worth doing and started over with a clean slate; we're developing a new Control Gallery app as we port each handler and control, cleaning them up and making them stable. Alongside that, we add a suite of tests run against the Avalonia Headless Test Runner.
As we've been going through and implementing more of the underlying stack, we have already started identifying areas in Avalonia where we could bring concepts and controls from .NET MAUI as first-class citizens. Javier has been on a roll, creating new controls, such as SwipeView, and API Specs to bring forward to the Avalonia team as a whole for consideration on whether we should include it in the broader framework.
Alongside features to Avalonia, like propagating letter spacing to every control and adding the StrokeMiterLimit property to Shape. These types of enhancements are major drivers for this project, as they give us insight into where to invest in Avalonia. You can expect more of them as we continue.
You can check out the updated WebAssembly ControlGallery here. We will be publishing new versions as we go, so you can see how we're progressing.
Beyond the Control Gallery application we've been demonstrating, we've also started porting existing Open Source .NET MAUI applications to our new libraries. This work helps us compare against existing, real-world .NET MAUI applications. We want to make it as straightforward as possible to add our libraries and get started, including build-time tools like Resizetizer, which transform images, SVGs, and fonts into resources that "just work."
MauiPlanets
MauiPlanets is a simple example application developed by Naweed Akram that demonstrates new, at the time, design and control concepts for .NET MAUI. It also includes a set of fonts and images used within the application through Resizetizer. Built on .NET 6, it was a prime target for conversion so we could establish fundamental control concepts and ensure "legacy" applications worked first as we moved to more advanced examples.
This example runs on Avalonia through our renderer with the same code as the original project. The only change we made was bumping it to .NET 10, and changing the Image URLs used for its gallery function (to avoid CORS issues with WebAssembly). With this, you can see support for the navigation stack, basic animation, and tap and gesture support. We also support Resizetizer; during the build, Resizetizer runs and converts the images and fonts for output, and we then bind these resources to Avalonia resources. When .NET MAUI requests one of these images, fonts, or files, we can map it to the Avalonia resource and resolve it.
You can check out the WebAssembly version of the app here.
Current Challenges and Progress
Over the years, there have been attempts by the community and the .NET MAUI team to identify ways for them to support platforms like GTK within the .NET MAUI repository directly, or how to open the necessary interfaces and platform infrastructure to allow others to create their own implementations using .NET MAUI Core Libraries, such as a test using WPF as a foundation.
For example, some .NET MAUI internals, like App Lifecycle Support, are marked internal and need to be opened up. We can work around these with some clever Roslyn code, but for a stable release, we need to either identify and open up the parts of the platform that require it or create new public APIs.
There are also conceptual issues with how the .NET MAUI Handlers are constructed; they are tightly coupled to native controls. A net10-ios target expects UIButton, nothing else, since it's bound to it in the source. The generic net10 platform, on the other hand, binds to Object. Binding it directly to a type makes sense from an API perspective, as it's easier to know which type it will return, so you don't have to check and cast yourself.
Still, it makes it challenging to swap out implementations with different control sets altogether. Our current workaround is focusing on platforms with generic target frameworks we can deploy to, such as Linux, WebAssembly, macOS, and Windows. Concentrating on those platforms first lets us focus on establishing and supporting the baseline infrastructure, so we can eventually expand to more platforms. Theoretically, if we can overcome these .NET type issues, there should be nothing preventing us from targeting platforms like iOS or Android with our handlers as well.
A key point here is that our project will not fork or hack .NET MAUI. We will not add another target framework for Avalonia support. We do not want to do type swizzling or any crazy behind-the-scenes magic (No ILMerge, no Mono.Cecil). You will not rely on any custom versions of .NET MAUI we provide for this project to run. Any changes we need to make to .NET MAUI to support this integration need to be in their upstream code.
Likewise, we will not add any Avalonia code or code explicitly intended for this project alone (For example, adding an InternalsVisibleTo with our namespace to their libraries) to the .NET MAUI repository. What we want to do in the .NET MAUI repository is allow anyone to build their own integrations (Like with GTK or macOS AppKit), like we are doing with ours. It doesn't help either team or the community as a whole if we keep this work between ourselves.
Timeline
The end goal is to have a stable release of our library by the time .NET 11 is released.
Currently, we are working in a private repository while developing the fundamental controls and concepts. While some projects we open source from the start, like our Impeller binding efforts with NImpleller, my fear is that opening it up too soon would lead to a rush of people trying to hack any and every .NET MAUI App they can to use our renderers before they are ready. Ensuring the foundation is in place is essential to all of us. We want to give everyone a fighting chance of getting their existing apps running and have a good time doing it, rather than being in pain and struggling.
With that, our goals are to open the repository and publish our first preview release alongside .NET MAUI's first public preview for .NET 11. We will follow .NET MAUI's release cadence and make new preview releases available when they are published, alongside nightly builds from our CI.
We are focused on Linux and WebAssembly, as .NET MAUI does not target those platforms, and we want to get them solid first. That said, we will not limit anyone from running this library on other Avalonia platforms, such as Windows or macOS. Ideally, in the future, we will be able to support all Avalonia targets for this project.
Coming Soon
As we continue tightening up our library for release, we will be publishing more posts and samples to document our progress.
If you're interested in the project, please register your interest here. For us in Engineering, we're especially interested in building control libraries (both native and drawn) that wish to add support for our libraries, as well as those with complex, NuGet-heavy applications. We want to make the experience of adding Avalonia-handler support as painless as possible for end users and control vendors, and your feedback will help us determine where to focus our efforts as we head toward opening our repository and releasing our first preview.
.NET Conf Session
An oft-asked question to the .NET MAUI team whenever they talk about their cross-platform support is, “Well, what about Linux?”
Last Month, we announced our intentions to bring Linux and WebAssembly support to .NET MAUI through Avalonia. And with that, they could finally answer the question. As we build Avalonia-based handlers and controls for .NET MAUI, we are working closely with them on this initiative, collaborating to identify and contribute the necessary upstream changes to the official .NET MAUI repository, ensuring our work benefits the entire ecosystem, including other platform implementers.
We saw tons of excitement and significant questions about how we would make it happen and when we would release it. At .NET Conf China 2025, I spoke about how we would deliver this, how we have progressed over the past Month, the challenges we faced, and the challenges .NET MAUI would need to overcome to enable true interoperability with third-party application frameworks like ours. You can view the talk on Bilibili or YouTube, and here I will elaborate on the points I raised during the talk.
.NET MAUI Handlers and Layout
First, let's talk specifics about how .NET MAUI renders its controls.
The core design of .NET MAUI's controls is in the Handler architecture: a lightweight, performance-focused bridge between cross-platform controls and native platform views. For example, when you create a Button in .NET MAUI, it renders as a UIButton on iOS, a MaterialButton on Android, and a native button on Windows, all surfaced from the IButton interface.
With Avalonia, this becomes vastly simplified. We build a single set of handlers with Avalonia and map those controls to existing Avalonia versions, extending or creating new implementations as needed. These handlers can then be deployed to any platform Avalonia targets, allowing for more .NET MAUI in more places.
For the current version of .NET MAUI, we can integrate it relatively seamlessly, with some exceptions; the .NET MAUI Handlers, their core library interfaces, and infrastructure are enough to allow us to overwrite the underlying system base. So long as our target platform does not overlap with any specific platform that .NET MAUI already targets, like iOS or Android, we can swap out implementations wholesale and replace the entire body of the app with a drawn version.
As Avalonia includes a SkiaSharp-based renderer, we can also leverage the existing Microsoft.Maui.Graphics and SkiaSharp.Controls.Maui libraries. As they all share SkiaSharp and its version of Skia, we can wrap these handlers with underlying Avalonia-based controls. From what we have seen so far, it allows for a wholesale one-to-one mapping of many controls with minimal changes, operating exactly as they would within a general .NET MAUI app. For example, AlohaKit, created by Javier Suárez, who recently joined us from the .NET MAUI team at Microsoft, is an experimental .NET MAUI project for implementing drawing controls in Maui.Graphics APIs. We can take their gallery app and, once we apply our libraries and platform support, run it unchanged. We hope this will make it easier for those already using these libraries to draw their controls and add more platforms to deploy to.
.NET MAUI's layout system works similarly. It uses an ILayoutHandler interface to position controls directly on platform primitives: UIView on iOS, View on Android, and FrameworkElement on WinUI. Notably, .NET MAUI's own layout controls (such as StackPanel) don't simply wrap the platform's native equivalents; MAUI handles the layout calculations itself, and positions views directly.
Since .NET MAUI handles positioning and constraint calculations on its own, we let it do the calculations and position it precisely as it specifies, then pass it directly to Avalonia. Once we implemented the ILayoutManager and CrossPlatform Calculations, many of the standard layout controls in .NET MAUI "just worked," and worked exceptionally well.
ControlGallery
The ControlGallery app we released alongside our initial blog post was a proof-of-concept application to demonstrate we could port .NET MAUI infrastructure enough to get some apps and controls up and running. I made some of them quite hastily (you could even say "vibed." I'm looking at you ListView.), but the intent was for a cost estimate for this project and its overall viability.
With it, we established it would be worth doing and started over with a clean slate; we're developing a new Control Gallery app as we port each handler and control, cleaning them up and making them stable. Alongside that, we add a suite of tests run against the Avalonia Headless Test Runner.
As we've been going through and implementing more of the underlying stack, we have already started identifying areas in Avalonia where we could bring concepts and controls from .NET MAUI as first-class citizens. Javier has been on a roll, creating new controls, such as SwipeView, and API Specs to bring forward to the Avalonia team as a whole for consideration on whether we should include it in the broader framework.
Alongside features to Avalonia, like propagating letter spacing to every control and adding the StrokeMiterLimit property to Shape. These types of enhancements are major drivers for this project, as they give us insight into where to invest in Avalonia. You can expect more of them as we continue.
You can check out the updated WebAssembly ControlGallery here. We will be publishing new versions as we go, so you can see how we're progressing.
Beyond the Control Gallery application we've been demonstrating, we've also started porting existing Open Source .NET MAUI applications to our new libraries. This work helps us compare against existing, real-world .NET MAUI applications. We want to make it as straightforward as possible to add our libraries and get started, including build-time tools like Resizetizer, which transform images, SVGs, and fonts into resources that "just work."
MauiPlanets
MauiPlanets is a simple example application developed by Naweed Akram that demonstrates new, at the time, design and control concepts for .NET MAUI. It also includes a set of fonts and images used within the application through Resizetizer. Built on .NET 6, it was a prime target for conversion so we could establish fundamental control concepts and ensure "legacy" applications worked first as we moved to more advanced examples.
This example runs on Avalonia through our renderer with the same code as the original project. The only change we made was bumping it to .NET 10, and changing the Image URLs used for its gallery function (to avoid CORS issues with WebAssembly). With this, you can see support for the navigation stack, basic animation, and tap and gesture support. We also support Resizetizer; during the build, Resizetizer runs and converts the images and fonts for output, and we then bind these resources to Avalonia resources. When .NET MAUI requests one of these images, fonts, or files, we can map it to the Avalonia resource and resolve it.
You can check out the WebAssembly version of the app here.
Current Challenges and Progress
Over the years, there have been attempts by the community and the .NET MAUI team to identify ways for them to support platforms like GTK within the .NET MAUI repository directly, or how to open the necessary interfaces and platform infrastructure to allow others to create their own implementations using .NET MAUI Core Libraries, such as a test using WPF as a foundation.
For example, some .NET MAUI internals, like App Lifecycle Support, are marked internal and need to be opened up. We can work around these with some clever Roslyn code, but for a stable release, we need to either identify and open up the parts of the platform that require it or create new public APIs.
There are also conceptual issues with how the .NET MAUI Handlers are constructed; they are tightly coupled to native controls. A net10-ios target expects UIButton, nothing else, since it's bound to it in the source. The generic net10 platform, on the other hand, binds to Object. Binding it directly to a type makes sense from an API perspective, as it's easier to know which type it will return, so you don't have to check and cast yourself.
Still, it makes it challenging to swap out implementations with different control sets altogether. Our current workaround is focusing on platforms with generic target frameworks we can deploy to, such as Linux, WebAssembly, macOS, and Windows. Concentrating on those platforms first lets us focus on establishing and supporting the baseline infrastructure, so we can eventually expand to more platforms. Theoretically, if we can overcome these .NET type issues, there should be nothing preventing us from targeting platforms like iOS or Android with our handlers as well.
A key point here is that our project will not fork or hack .NET MAUI. We will not add another target framework for Avalonia support. We do not want to do type swizzling or any crazy behind-the-scenes magic (No ILMerge, no Mono.Cecil). You will not rely on any custom versions of .NET MAUI we provide for this project to run. Any changes we need to make to .NET MAUI to support this integration need to be in their upstream code.
Likewise, we will not add any Avalonia code or code explicitly intended for this project alone (For example, adding an InternalsVisibleTo with our namespace to their libraries) to the .NET MAUI repository. What we want to do in the .NET MAUI repository is allow anyone to build their own integrations (Like with GTK or macOS AppKit), like we are doing with ours. It doesn't help either team or the community as a whole if we keep this work between ourselves.
Timeline
The end goal is to have a stable release of our library by the time .NET 11 is released.
Currently, we are working in a private repository while developing the fundamental controls and concepts. While some projects we open source from the start, like our Impeller binding efforts with NImpleller, my fear is that opening it up too soon would lead to a rush of people trying to hack any and every .NET MAUI App they can to use our renderers before they are ready. Ensuring the foundation is in place is essential to all of us. We want to give everyone a fighting chance of getting their existing apps running and have a good time doing it, rather than being in pain and struggling.
With that, our goals are to open the repository and publish our first preview release alongside .NET MAUI's first public preview for .NET 11. We will follow .NET MAUI's release cadence and make new preview releases available when they are published, alongside nightly builds from our CI.
We are focused on Linux and WebAssembly, as .NET MAUI does not target those platforms, and we want to get them solid first. That said, we will not limit anyone from running this library on other Avalonia platforms, such as Windows or macOS. Ideally, in the future, we will be able to support all Avalonia targets for this project.
Coming Soon
As we continue tightening up our library for release, we will be publishing more posts and samples to document our progress.
If you're interested in the project, please register your interest here. For us in Engineering, we're especially interested in building control libraries (both native and drawn) that wish to add support for our libraries, as well as those with complex, NuGet-heavy applications. We want to make the experience of adding Avalonia-handler support as painless as possible for end users and control vendors, and your feedback will help us determine where to focus our efforts as we head toward opening our repository and releasing our first preview.
.NET Conf Session
An oft-asked question to the .NET MAUI team whenever they talk about their cross-platform support is, “Well, what about Linux?”
Last Month, we announced our intentions to bring Linux and WebAssembly support to .NET MAUI through Avalonia. And with that, they could finally answer the question. As we build Avalonia-based handlers and controls for .NET MAUI, we are working closely with them on this initiative, collaborating to identify and contribute the necessary upstream changes to the official .NET MAUI repository, ensuring our work benefits the entire ecosystem, including other platform implementers.
We saw tons of excitement and significant questions about how we would make it happen and when we would release it. At .NET Conf China 2025, I spoke about how we would deliver this, how we have progressed over the past Month, the challenges we faced, and the challenges .NET MAUI would need to overcome to enable true interoperability with third-party application frameworks like ours. You can view the talk on Bilibili or YouTube, and here I will elaborate on the points I raised during the talk.
.NET MAUI Handlers and Layout
First, let's talk specifics about how .NET MAUI renders its controls.
The core design of .NET MAUI's controls is in the Handler architecture: a lightweight, performance-focused bridge between cross-platform controls and native platform views. For example, when you create a Button in .NET MAUI, it renders as a UIButton on iOS, a MaterialButton on Android, and a native button on Windows, all surfaced from the IButton interface.
With Avalonia, this becomes vastly simplified. We build a single set of handlers with Avalonia and map those controls to existing Avalonia versions, extending or creating new implementations as needed. These handlers can then be deployed to any platform Avalonia targets, allowing for more .NET MAUI in more places.
For the current version of .NET MAUI, we can integrate it relatively seamlessly, with some exceptions; the .NET MAUI Handlers, their core library interfaces, and infrastructure are enough to allow us to overwrite the underlying system base. So long as our target platform does not overlap with any specific platform that .NET MAUI already targets, like iOS or Android, we can swap out implementations wholesale and replace the entire body of the app with a drawn version.
As Avalonia includes a SkiaSharp-based renderer, we can also leverage the existing Microsoft.Maui.Graphics and SkiaSharp.Controls.Maui libraries. As they all share SkiaSharp and its version of Skia, we can wrap these handlers with underlying Avalonia-based controls. From what we have seen so far, it allows for a wholesale one-to-one mapping of many controls with minimal changes, operating exactly as they would within a general .NET MAUI app. For example, AlohaKit, created by Javier Suárez, who recently joined us from the .NET MAUI team at Microsoft, is an experimental .NET MAUI project for implementing drawing controls in Maui.Graphics APIs. We can take their gallery app and, once we apply our libraries and platform support, run it unchanged. We hope this will make it easier for those already using these libraries to draw their controls and add more platforms to deploy to.
.NET MAUI's layout system works similarly. It uses an ILayoutHandler interface to position controls directly on platform primitives: UIView on iOS, View on Android, and FrameworkElement on WinUI. Notably, .NET MAUI's own layout controls (such as StackPanel) don't simply wrap the platform's native equivalents; MAUI handles the layout calculations itself, and positions views directly.
Since .NET MAUI handles positioning and constraint calculations on its own, we let it do the calculations and position it precisely as it specifies, then pass it directly to Avalonia. Once we implemented the ILayoutManager and CrossPlatform Calculations, many of the standard layout controls in .NET MAUI "just worked," and worked exceptionally well.
ControlGallery
The ControlGallery app we released alongside our initial blog post was a proof-of-concept application to demonstrate we could port .NET MAUI infrastructure enough to get some apps and controls up and running. I made some of them quite hastily (you could even say "vibed." I'm looking at you ListView.), but the intent was for a cost estimate for this project and its overall viability.
With it, we established it would be worth doing and started over with a clean slate; we're developing a new Control Gallery app as we port each handler and control, cleaning them up and making them stable. Alongside that, we add a suite of tests run against the Avalonia Headless Test Runner.
As we've been going through and implementing more of the underlying stack, we have already started identifying areas in Avalonia where we could bring concepts and controls from .NET MAUI as first-class citizens. Javier has been on a roll, creating new controls, such as SwipeView, and API Specs to bring forward to the Avalonia team as a whole for consideration on whether we should include it in the broader framework.
Alongside features to Avalonia, like propagating letter spacing to every control and adding the StrokeMiterLimit property to Shape. These types of enhancements are major drivers for this project, as they give us insight into where to invest in Avalonia. You can expect more of them as we continue.
You can check out the updated WebAssembly ControlGallery here. We will be publishing new versions as we go, so you can see how we're progressing.
Beyond the Control Gallery application we've been demonstrating, we've also started porting existing Open Source .NET MAUI applications to our new libraries. This work helps us compare against existing, real-world .NET MAUI applications. We want to make it as straightforward as possible to add our libraries and get started, including build-time tools like Resizetizer, which transform images, SVGs, and fonts into resources that "just work."
MauiPlanets
MauiPlanets is a simple example application developed by Naweed Akram that demonstrates new, at the time, design and control concepts for .NET MAUI. It also includes a set of fonts and images used within the application through Resizetizer. Built on .NET 6, it was a prime target for conversion so we could establish fundamental control concepts and ensure "legacy" applications worked first as we moved to more advanced examples.
This example runs on Avalonia through our renderer with the same code as the original project. The only change we made was bumping it to .NET 10, and changing the Image URLs used for its gallery function (to avoid CORS issues with WebAssembly). With this, you can see support for the navigation stack, basic animation, and tap and gesture support. We also support Resizetizer; during the build, Resizetizer runs and converts the images and fonts for output, and we then bind these resources to Avalonia resources. When .NET MAUI requests one of these images, fonts, or files, we can map it to the Avalonia resource and resolve it.
You can check out the WebAssembly version of the app here.
Current Challenges and Progress
Over the years, there have been attempts by the community and the .NET MAUI team to identify ways for them to support platforms like GTK within the .NET MAUI repository directly, or how to open the necessary interfaces and platform infrastructure to allow others to create their own implementations using .NET MAUI Core Libraries, such as a test using WPF as a foundation.
For example, some .NET MAUI internals, like App Lifecycle Support, are marked internal and need to be opened up. We can work around these with some clever Roslyn code, but for a stable release, we need to either identify and open up the parts of the platform that require it or create new public APIs.
There are also conceptual issues with how the .NET MAUI Handlers are constructed; they are tightly coupled to native controls. A net10-ios target expects UIButton, nothing else, since it's bound to it in the source. The generic net10 platform, on the other hand, binds to Object. Binding it directly to a type makes sense from an API perspective, as it's easier to know which type it will return, so you don't have to check and cast yourself.
Still, it makes it challenging to swap out implementations with different control sets altogether. Our current workaround is focusing on platforms with generic target frameworks we can deploy to, such as Linux, WebAssembly, macOS, and Windows. Concentrating on those platforms first lets us focus on establishing and supporting the baseline infrastructure, so we can eventually expand to more platforms. Theoretically, if we can overcome these .NET type issues, there should be nothing preventing us from targeting platforms like iOS or Android with our handlers as well.
A key point here is that our project will not fork or hack .NET MAUI. We will not add another target framework for Avalonia support. We do not want to do type swizzling or any crazy behind-the-scenes magic (No ILMerge, no Mono.Cecil). You will not rely on any custom versions of .NET MAUI we provide for this project to run. Any changes we need to make to .NET MAUI to support this integration need to be in their upstream code.
Likewise, we will not add any Avalonia code or code explicitly intended for this project alone (For example, adding an InternalsVisibleTo with our namespace to their libraries) to the .NET MAUI repository. What we want to do in the .NET MAUI repository is allow anyone to build their own integrations (Like with GTK or macOS AppKit), like we are doing with ours. It doesn't help either team or the community as a whole if we keep this work between ourselves.
Timeline
The end goal is to have a stable release of our library by the time .NET 11 is released.
Currently, we are working in a private repository while developing the fundamental controls and concepts. While some projects we open source from the start, like our Impeller binding efforts with NImpleller, my fear is that opening it up too soon would lead to a rush of people trying to hack any and every .NET MAUI App they can to use our renderers before they are ready. Ensuring the foundation is in place is essential to all of us. We want to give everyone a fighting chance of getting their existing apps running and have a good time doing it, rather than being in pain and struggling.
With that, our goals are to open the repository and publish our first preview release alongside .NET MAUI's first public preview for .NET 11. We will follow .NET MAUI's release cadence and make new preview releases available when they are published, alongside nightly builds from our CI.
We are focused on Linux and WebAssembly, as .NET MAUI does not target those platforms, and we want to get them solid first. That said, we will not limit anyone from running this library on other Avalonia platforms, such as Windows or macOS. Ideally, in the future, we will be able to support all Avalonia targets for this project.
Coming Soon
As we continue tightening up our library for release, we will be publishing more posts and samples to document our progress.
If you're interested in the project, please register your interest here. For us in Engineering, we're especially interested in building control libraries (both native and drawn) that wish to add support for our libraries, as well as those with complex, NuGet-heavy applications. We want to make the experience of adding Avalonia-handler support as painless as possible for end users and control vendors, and your feedback will help us determine where to focus our efforts as we head toward opening our repository and releasing our first preview.
.NET Conf Session
