In hindsight, I should have adopted used this in the past for the apps of my startup, instead of going for the Xamarin.Forms route.
Why do I say this? Because the migration from Xamarin.Forms to MAUI was (actually, _is_, as it's not really 100% finished yet) a horrible PITA.
Let alone the migration from .NETFramework to .NETCore (now called "dotnet" since v5) which delayed us months if not years (but people that used Avalonia would be affected by this too; so the way to dodge all this would have been choosing Flutter or ReactNative, I guess).
That being said, the main reason why I chose Xamarin.Forms over Avalonia at the time is because the latter didn't have Mobile support. How's Avalonia's mobile support now? Even if the port is 100% complete, I always thought "well, XF/Maui are centered around mobile, making desktop just be an after-thought", which to me is an advantage because I prefer better UX for mobile by default, and require devs to spend extra effort for desktop support (instead of the other way around); given that desktop usage of apps is declining day by day.
I've only ever seen mobile mentioned as "coming soon", but honestly, I don't think porting over the GUI library will make turning an application into a mobile one any easier. A mouse+keyboard design just doesn't fit a mobile screen well, you're going to need to redesign and reimplement large parts of your application regardless of what platform you pick. You'll probably get tablets working easily, but for mobile phones you'll need to put in the annoying grunt work.
I do like Avalonia for actually bringing a cross-platform .NET GUI to Linux and for that purpose it works quite well. I'm sure the toolkit will end up working fine for mobile just fine, as long as you design your application for the different form factors you may end up running on. Porting Xamarin Forms to Avalonia is going to be a hell of a lot easier than porting it to Flutter or React Native, but you'll still end up putting significant effort into the process if you want it to succeed.
Avalonia's big money-maker is their drop-in replacement platform for WPF, which allows you to basically take an old WPF application and turn it into a Windows/macOS/Linux/web application with two lines of code, if you're willing to pay the price. Perhaps they'll add some kind of auto-mobile-form-factor conversion to that system as well?
>> Avalonia's big money-maker is their drop-in replacement platform for WPF, which allows you to basically take an old WPF application and turn it into a Windows/macOS/Linux/web application with two lines of code, if you're willing to pay the price
Forgive my ignorance. But what "price" you are talking about, money, or dev time spent to root out the kinks?
I have a WPF application running on Windows, and I am thinking about porting it to Avalonia for the purpose of cross platform. Just for the background
Money, specifically $20k per app per platform (assuming you're not a small startup). That's Avalonia XPF, though, not the open source component; XPF is an alternative platform to target that'll turn WPF into Avalonia without rewriting any code.
If you're willing to rewrite/port code, you can use the open source stuff and get the benefits for free, of course!
> Avalonia's big money-maker is their drop-in replacement platform for WPF, which allows you to basically take an old WPF application and turn it into a Windows/macOS/Linux/web application with two lines of code, if you're willing to pay the price. Perhaps they'll add some kind of auto-mobile-form-factor conversion to that system as well?
Ah interesting, I didn't know this.
> A mouse+keyboard design just doesn't fit a mobile screen well, you're going to need to redesign and reimplement large parts of your application regardless of what platform you pick.
I think you're understanding this backwards. I'm not aiming to port a desktop app to a mobile app, I'm aiming to choose a UI toolkit that works fine in mobile by default and requires tweaks in your app to make it work in desktop (rather than choosing a UI toolkit that works fine in desktop by default but requires tweaks in your app to make it work in mobile).
The web? That's the opposite of what was requested here. Most websites look good on desktop but require tweaks to be seen properly on mobile. Not the other way around.
> Most websites look good on desktop but require tweaks to be seen properly on mobile.
This is a weird take. Most web browsing these days is done on a mobile device. Even HN, with its table-based layout, works completely fine on a phone, because it has to- at some point someone put in the minimum to make it work nicely on a mobile screen (basically one meta attribute and perhaps a few CSS media queries). You can build a single web app (without detecting the user's device and switching versions) that scales from the smallest phone to a theater screen thanks to media queries and CSS.
It's even a best practice manifested as "Mobile First Design" that it's better to build a mobile web app first, and get that right, then use responsiveness and media queries to iterate that into a desktop version. I personally think this is a debateable proposition, but it seems weird to state that "most look good on desktop but require tweaks to be seen properly on mobile", when it is in fact the case that most websites and apps are designed for mobile first.
The web is fully capable of delivering an appropriate experience across all form factors, on websites and on web apps. If the web can do it, I don't think it's a pipe dream to capture that capability in a non-web native/cross-plat UI framework designed to do what the web is already doing today. Admittedly CSS is big and crazy and insanely powerful because it has to be, and is probably overkill outside of HTML (though I've seen some UI frameworks approximate it), but a middle ground is definitely possible if you think creatively about it.
Now "possible" and "it exists" are two different things- that's why the web is such an alluring platform: It is probably the single most powerful and flexible user interface framework (in a sense) ever designed.
I'm not sure if "any" applies, I'm sure there are some weird proprietary WPF components out there that'll break somehow. However, XPF does seem to integrate well with popular WPF widget libraries, so support seems very good.
It seems so, I have been looking into AvaloniaUI for a product and read several articles about people having success porting fairly complex WPF apps that use third-party components like grids.
the move from framework to core should be smooth outside of a few areas.
- webforms/asp.net framework won't move over easily
- windows GUI apps won't move over easily
- some windows specific API's didn't come over (such as WPF).
If your app falls into any (or multiple) of the above then you definitely would have experienced pain, but in general the move is pretty smooth.
Yes, I so wish I had gone with Avalonia 3 years ago. I now have a Xamarin.Forms app that is at the end of life, and MAUI media player options are dismal.
I just learned about this today, and this (from the FAQ) helped me understand how to think about it:
"Avalonia is akin to Flutter for .NET, both using Skia for UI rendering. Key differences include Avalonia's use of .NET and XAML, contrasting with Flutter's Dart language. While Flutter excels in mobile, Avalonia has recently expanded to mobile, offering a more mature desktop experience. For teams skilled in .NET and XAML, Avalonia is likely the better fit."
So this might be a great choice if you're a .NET shop, if your app doesn't need a platform-native native look or feel, and if your project is desktop-focused.
I have yet to find any fast UI framework that uses Skia. It seems it's great for mostly static pages (like old style HTML) but as soon as you do animations and desktop resolutions, Skia's CPU rendering will fall apart.
Case in point, none of the Flutter examples are smooth on my 4K laptop. But I can play Assassin's Creed Mirage (released a few months ago) just fine at 70+ fps.
My understanding is that rendering large text blocks with Skia will max out the CPU. So they would need to chunk the content of the div inside the scroll container, like what Chrome does.
It shows pretty large colorized texts so you can estimate how Direct2D and Skia handle GPU accelerated text rendering. For these two binaries the difference is only in graphics used - Direct2D and Skia.
Would be curious to see an example of what you consider a fast UI. (I hear Skia is faster than most alternatives like Cairo, so your statement makes me think that rendering 2D UIs is just slow in general.)
Last time I tried Avalonia UI on Mac, the CPU usage was really high (like in the 70s sometimes without doing anything). They might have addressed that since then though.
I think mostly it's just that many existing tools use CPU rendering. Without "modern" pixel shaders, crisp anti-aliased text rendering was pretty much impossible on GPU. At 800x600, rendering the UI on CPU used to be no problem. But with retina and high-DPI it became 4x slower and, thereby, unusable.
And yes, that high CPU usage is exactly the issue with Skia. Ideally, it should require a few percent on load and then afterwards everything should be running inside the GPU at almost 0% CPU cost.
I have to disagree that the high CPU usage I mentioned is an issue with Skia in the case of Avalonia.
Other frameworks like Flutter which use Skia don't have such a high CPU load on my computer so I'm pretty sure the high CPU usage is because of Avalonia specifically. (Although Skia might very well contribute to it.)
Just opened Chrome and Firefox (both of which use Skia) and both used about 1% CPU while idle while Avalonia is there with up to 70% CPU usage while idle.
My guess would be that Avalonia is doing something stupid like re-drawing the entire GUI on every mouse cursor movement (in case any hover effect changed) and then Skia is transforming that into high CPU usage. Games using proper GPU acceleration can get away with drawing highly complex GUIs at 144 FPS with negligible CPU usage [1], so while it is wasteful to constantly re-draw an application GUI, that alone will not lead to excessive CPU usage just yet.
That sounds reasonable to me. I remember game loops being split into one draw() and one update() function and would expect UI frameworks to be the same.
I think, in games, it's usual to traverse twice through each object in a graph on each loop, once for drawing and once for updating/handling interactions.
Am I right guessing that UI frameworks do something similar? One update function traversing through each widget to check for interactions. Then two drawing-related functions, with one checking for each object whether it changed and needs to be redrawn, and the second drawing just those widgets that changed?
I'm trying to think in terms of Big O, and it doesn't sound unreasonable to drop the change-calcylation function and redraw from scratch because that way you would have two O(n) functions instead of three. Maybe the constant factor of drawing pixels to the screen is high enough to outweigh that additional change-detection loop.
"Am I right guessing that UI frameworks do something similar?"
most of them try to avoid the update() loop because UI elements usually only change if the application state changes (and then you call paint() or invalidate()) or if the window moves or gets dis-occluded (then the OS calls invalidate()) or if the mouse cursor moves.
So typically, the UI framework will have a "dirty" rectangle flag which represents the pixel area that needs to be redrawn.
Slight sidetrack, but Noesis is free for < $100k revenue, and the licenses for use above that are very affordable and royalty free.
The only problem I had is that IDE support is limited. At least at the time I was using it, Microsoft Blend felt very much like a half functioning and abandoned project that was just being dragged along for the sake of maintaining something at least reminiscent of an IDE.
I'm talking from memory (tried opening the FluentAvalonia sample so the styling may have affected it), but I will try again later and post results hopefully.
Just checked and I'm getting about 5% CPU on idle, with no animations (for FluentAvalonia) and about 30% (did observe 40% once but was an edge case) when animations are playing on screen.
Sorry for the misinformation. (I can't edit my previous post unforunately because of how HN works.)
It's even worse. Skia can use system native font handling, but in a half-baked way, so chrome always has font rendering issue on windows, and any skia based project probably suffers same issue. Firefox tries to avoid it by handling font directly.
This is strange to me because Skia is the rendering backend used by Firefox and Chrome in many cases, and AFAIK it has hardware acceleration. Why is it using the CPU?
I believe it's caching the text as GPU texture and then accelerating only the compositing. That's also why you can't directly draw formatted text into a WebGL context. And for pages consisting mostly of static text, it's perfectly acceptable.
"GPU accelerated rendering means that the GPU is used for composition."
Chromium (and Firefox) do GPU accelerated raster as well as composition. That page you linked is about a very specific case of wanting to get the pixels back to reuse in a different context. In that situation doing the work on the GPU and then copying back to the CPU may be slower than keeping it on the CPU the whole time.
suggests to me that the glyph rasterization (which is the CPU-limiting factor for text rendering) in WebRender (which is the new FF 93+ GPU-accelerated rendering engine) is implemented in Rust and to be run on CPU. On Linux it appears to use FreeType (which is CPU-only):
Do you use Chrome (on non iOS platforms) or Android? Both are made in Skia, and I don't just mean they can render Skia apps like Flutter apps, I mean that literally the system views themselves are all in Skia. Native Android apps that aren't in Flutter are also rendered via Skia.
Yes, I sometimes test on Chrome. And I have also implemented JavaScript workarounds because Chrome still cannot handle a plain <table> with 750 rows where each row has a 120px image thumbnail and some text columns without gobbling up gigabytes of memory and/or freezing on weaker machines.
I agree with you that both Chrome and Android work quite well in general. But that doesn't change the fact that some of the design decisions have aged badly:
"Chrome is still the king resource hog on macOS"
"In previous tests, which included a lot more tab switching, and no WebGL and media consumption, Safari was using 10x less than Chrome"
9 years ago, I myself also shipped apps that were rendering the GUI exclusively on CPU because it's just so much easier to get things to look 100% identical everywhere. But nowadays, those apps are either pixelated or feel sluggish even on modern Macs because Retina displays have easily 4x-ed the number of pixels that need to be drawn. But single-threaded FLOPS has not 4x-ed since then.
What alternative do you propose? What other library is cross-platform, has a nice API, performant, supports text well enough, and can do both CPU and GPU rendering?
What the hell are we doing as an industry? We have 20 cores per CPU and enough RAM to fit the entire human civilization's knowledge in text form in everyone's pocket, but we can't scroll a webpage with animations without stuttering?
Just like every other industry, we're trying to deliver at the lowest possible price, which leads to the lowest acceptable quality level.
It would be easy to add 20% of time and budget to a project and just let your developers work on bugfixes and improvements. Maybe even let your dev team interview a customer or two to truly understand what matters to them. But that's considered too expensive. (even though some SaaS have 90%+ profit margins)
I would add to the above: like every other sector, we are sitting on top of a teetering arbitrary pile of technologies and processes that is long past due for a cleanup and overhaul, but we still haven't encountered a catastrophe big enough to motivate us to devote the resources.
Because it's cheap. You can add a ton of bling with little effort by piling on abstraction layer on top of abstraction layer so your cheapest bootcamp trained Javascript developers can write flashy GUIs without prior experience.
As long as your tool demo works slickly on the highest performance Macbooks used by the execs you're trying to sell to, performance isn't a factor.
Avalonia is interesting because so many desktop apps have been made in WPF over the past decades. And now the technology is getting old and MS wants to replace it by unproven frameworks which have various drawbacks. As Avalonia is XAML based just like WPF, it is a good way to upgrade old apps and make them multiplatform in one go.
For mobile or web it would not be my first choice. And desktop apps may not sound as sexy. But there is definitely a category of applications that works best as a desktop app and shouldn't be replaced by the web.
WPF still works, but it's tied to DirectX 9 in various ways and doesn't get more than a few bugfixes. It's also used for Visual Studio, albeit with .NET Framework, so any changes risk breaking one fairly complex product (while nothing at MS uses Windows Forms, as far as I know).
I can speak in favor of Avalonia from experience [1] for exactly this use case:
- You want to target Windows, macOS, Linux, Android, iOS, and browser from one codebase.
- You've already decided to use .NET / XAML. (So you're not comparing to e.g. Flutter)
I chose Avalonia over the alternatives [2] that also match this criteria. It's been a good experience, and I'm overall happy with the app. The solution template "just works" on all platforms, and iteration from it to my finished app was straightforward. I found libraries for everything, whether Avalonia-specific or just .NET. The Avalonia community is active, and the devs are responsive on GitHub. Avalonia as a company will be around as they have a strong business model selling XPF.
Some downsides are:
- Mobile is not as polished. Avalonia started on desktop and expanded to other platforms. Some controls feel awkward on mobile, because they were originally for desktop. Example: TextBox. If Mobile is your primary concern, consider Uno or Xamarin [2].
- The "non-native controls" approach has pros and cons. Your controls render the same everywhere, but they can feel out of place, depending on your styling. For example, buttons in my app don't look like iOS buttons, which Apple cares about a lot. However, my users already familiar with the look on Windows or Android can easily use the app on iOS and vice-versa.
- Build times for mobile and web are slow. I mostly edit-compile-debug on desktop and then smoke test on other platforms.
- You still have the usual deployment and distribution challenges for each platform: desktop installers; macOS requires notarization; iOS requires App Store review. For most of that, Avalonia has excellent docs [3] and there are supporting libraries [4].
I've tried it and didn't like it at all. It's a memory hog, start-up times are horrendous, I've had lots of glitches on MacOS and I detest XAML. Overall it really feels like yet another alpha state product.
Besides, I'm not really keen on using Microsoft products. Right now I have big hopes for Iced on Rust.
MS Teams devs obviously feel the same as they didn't bother using any of this stuff (Maui, Avalonia, Xamarin). I get the sense the Microsoft groups developing these technologies are suffering from MIC (Manager is Customer) syndrome.
It's super fast if you use Native AOT. My entire application starts up in 0.3 seconds, that includes Avalonia and all my code too. It does use more memory than I'd like though, about 200 MB.
>We use Avalonia for our Product and honestly couldn’t be happier.
What do you mean "couldn't be happier"? Start-up times and memory consumption are objectively bad. Also something someone else already mentioned in here: font rendering just feels really off.
>On desktop (Apple M2) it pretty much feels instant to me.
Why are you lying? It's not quick, let alone "pretty much instant". Neither on my M3 nor on my gaming machine. Actually I think Avalonia's start-up time is the worst out of all GUI frameworks I've used so far, including Electron.
As someone with a good grasp of WPF who intends to rewrite an existing desktop C# WinForms (windows only) application to Avalonia, with the express goal of having a single, cross-platform codebase for (at least) Windows and MacOS…
Does anyone have any experiences on doing something similar? Are there any non-obvious pitfalls one risk falling into one should consider upfront?
I am in the process of writing an Avalonia app now and one thing to consider is the controls that you will need. WinForms has a lot available and Avalonia’s coverage isn’t as broad. Hoping it improves over time. Other than that, if you know WPF I think you will enjoy the experience. It has been fun for me so far and I would encourage others to try it out.
WPF and Xamarin dev here who wrote a new (not ported) codebase on Avalonia.
- Avalonia has a guide just for people like you and me [1].
- Avalonia's flavor of XAML has small divergences from WPF that will have you hitting their docs often. There are some nice quality-of-life improvements, for example you can bind a Button click handler directly to a method without ICommand. The major concepts are the same e.g. data binding, dependency properties.
- Coming from WPF, it's possible you've used MVVM and dependency injection. You'd be going against a strong cultural grain to not use them in Avalonia. But I would be surprised if your WinForms app is architected like that, so it may be a design challenge extracting coherent ViewModels and properties from the ball of mud that many WinForms apps become.
- For macOS, read up on notarization [2] and, if you're publishing to the Mac App Store, the review process.
- I recommend starting with example apps (look in the Showcase) or with the Avalonia template solution which just runs out of the box.
- The Avalonia team iterates quickly. Expect to upgrade NuGets frequently, and don't get too far behind. There was recently a big jump from version 10 to 11. Good for you for starting after that.
- Not Avalonia specifically but if you're not used to .NET Core check out #nullable enable. Can't live without it now, but was confusing at first.
- Be sure to check out all of the official and community libraries [3]. I bet my design big on `ReactiveUI` and it's gone well.
To name a few: Schneider Electric, JetBrains, GitHub, Datadog, AMD, KLM, Moodys Analytics and tons more.
There’s no catch. The project is OSS (MIT license) and has been since the projects inception over a decade ago. There isn’t a paid version of Avalonia at all, so no gatekeeping of features. We instead generate revenue from support agreements, development services and selling our cross-platform fork of WPF. You can read a little more about it on our blog: https://avaloniaui.net/Blog/balancing-growth-and-sustainabil...
Production user here. I've found no money "gotchas". They're above reproach. In fact, I've received considerable free support from their devs on GitHub Issues [1].
The Avalonia business model is based on selling XPF, which runs WPF (Windows-only) apps on other platforms. That's very interesting to big corps with existing codebases.
So perhaps not “production” in the terms you’re thinking of but I’ve built https://roadcaptain.nl with AvaloniaUI and I’ve been pretty happy with both the results as well as the developer experience.
One of my requirements was a cross platform UI framework _for desktop_ as I target Windows, Linux and macOS.
Look and feel is totally custom and not using native elements by choice. So if you’re looking to do that AvaloniaUI might not be what you want
Going to check this later. Have heard good things and really like using C# anywhere possible. C++, python etc have so massive compromises for just enjoyable development and good results.
This seems like a perfect framework to use for embedded SCADA/HMI systems. I’ve been debating home brewing my own system but this should be a great replacement.
I think that depends on your definition of high profile. The site has a showcase link in the header and the big names that popped out to me were JetBrains and GitHub.
> JetBrains Rider
> JetBrains uses Avalonia UI to enable DotMemory and DotTrace to run within Rider, their cross-platform IDE.
> Git Credential Manager
> Developed by GitHub, Git Credential Manager is a universal solution for Git authentication.
Do you mean accessibility? I did notice disappointing non-native-like behaviours when I tried typing in an AvaloniaUI textbox but I'm hopeful they will manage to solve that and other issues.
For example, pressing a space will always introduce a new item in the undo/redo history [0] which isn't how native textboxes work.
Eco probably means ecosystem, which I assume it means lack of UI Controls like Maps view, Graph/Charts for visualizing data, Date pickers and other stuff they you can get from vibrant UI ecosystem.
But I think some of this stuff is already handled in Avalonia ecosystem like https://github.com/Mapsui/Mapsui, https://github.com/beto-rodriguez/LiveCharts2 and few others...
Why do I say this? Because the migration from Xamarin.Forms to MAUI was (actually, _is_, as it's not really 100% finished yet) a horrible PITA.
Let alone the migration from .NETFramework to .NETCore (now called "dotnet" since v5) which delayed us months if not years (but people that used Avalonia would be affected by this too; so the way to dodge all this would have been choosing Flutter or ReactNative, I guess).
That being said, the main reason why I chose Xamarin.Forms over Avalonia at the time is because the latter didn't have Mobile support. How's Avalonia's mobile support now? Even if the port is 100% complete, I always thought "well, XF/Maui are centered around mobile, making desktop just be an after-thought", which to me is an advantage because I prefer better UX for mobile by default, and require devs to spend extra effort for desktop support (instead of the other way around); given that desktop usage of apps is declining day by day.