[HN Gopher] MAUI Is Coming to Linux
___________________________________________________________________
MAUI Is Coming to Linux
Author : DeathArrow
Score : 129 points
Date : 2026-03-22 15:43 UTC (7 hours ago)
(HTM) web link (avaloniaui.net)
(TXT) w3m dump (avaloniaui.net)
| Ciantic wrote:
| I wish they support Linux wholeheartedly, a lot of toolkits and
| GUI frameworks do it by half-assing things, mostly because
| Wayland is difficult to understand.
|
| In Wayland you have multiple ways to render windows, not just the
| XDG top level window. It works via surfaces, and here is a list
| I've discovered so far: - XDG Top Level Window
| - Child Window - Popup Surface - Layer surface (like
| task-bars, shell overlays) - Subsurface (region in another
| surface) - IME Panel Surface (surface that follows text
| cursor)
|
| There probably is others too.
|
| It is diffifcult to find high-level toolkits that support all of
| the above.
| Pay08 wrote:
| Not to mention that there's no clear documentation for this
| anywhere. A while ago I was attempting to debug some Wayland-
| specific issues with a graphics library, it turns out the issue
| was that the little documentation there was, was wrong about
| what is and isn't nullable.
| OtomotO wrote:
| I found https://wayland.app/protocols/ very helpful so far.
|
| That and studying smithay code.
| Pay08 wrote:
| That was the documentation with the incorrect nullability I
| was referencing.
| mahkoh wrote:
| I doubt there is anything incorrect there. See the note
| here: https://wayland.freedesktop.org/docs/book/Message_X
| ML.html#a...
| audidude wrote:
| In X11 we kept things simple by offering:
|
| * Core protocol drawing (lines, rectangles, arcs, the classics)
|
| * XRender for compositing and alpha
|
| * XShm for shared-memory blits
|
| * GLX if you felt like bringing a GPU to a 2D fight
|
| * XVideo for overlay video paths
|
| * Pixmaps vs Windows, because why have one drawable when you
| can have two subtly different ones
|
| * And of course, indirect rendering over the network if you
| enjoy latency as a design constraint
| shevy-java wrote:
| Wayland is a mess.
|
| Perhaps https://github.com/X11Libre/xserver can revive the
| older ecosystem. Almost nobody writes for wayland. About two
| years ago I tried to switch, then gave up when I realised how
| many things are missing on wayland. And then I noticed that
| barely anyone wrote software for wayland. It feels like a
| corporate advertisement project really. GNOME and KDE push for
| wayland now.
| LeFantome wrote:
| What does "nobody writes for Wayland" mean?
|
| If you write software using GTK, Qt, or FLTK then you are
| writing Wayland software.
|
| The majority of Linux desktops are Wayland at this point.
| Nobody writes software for them?
|
| The Steamdeck uses gamescope which is Wayland. GNOME, COSMIC,
| Budgie, Niri, and Hyprland are not just Wayland but Wayland
| only. KDE will be Wayland only soon. Cinnamon is switching to
| Wayland. XFCE is writing a Wayland compositor.
|
| What percentage of Linux desktop users are not using one of
| the above? 10 at most?
| noselasd wrote:
| It just means "noone" uses the wayland APIs directly, but
| instead they leave the wayland complexity to GTK,Qt or
| FLTK, and they call their app a Qt app, not a Wayland app.
| simonh wrote:
| Was X11 any different in practice? Apart from ancient
| legacy stuff like XTerm. It would be like writing a Mac
| application in Quartz directly.
| Gigachad wrote:
| You have to go quite out of your way to not use Wayland.
| Pretty much all mainstream distros switched over long ago.
| This just feels like the systemd drama restarted. Some will
| complain and hold on to the past for as long as they can but
| the rest of the world moves on. Wayland is the better choice
| today.
| eikenberry wrote:
| I think Wayland is basically waiting for a higher level
| abstraction to fully replace X11, at least for the desktop.
| I'm currently playing with the River Wayland compositor
| (https://codeberg.org/river/river) which separates the window
| manager from the compositor and I think it could fill this
| gap left in the transition. Not as sure about non-toolkit
| (gtk,qt) application development...
| moondev wrote:
| Things like this remind me how much I love open source
| software. Choice is amazing shout out to all the
| contributors!
| sandreas wrote:
| For everyone interested in Avalonia's Linux / Wayland strategy:
|
| https://avaloniaui.net/blog/bringing-wayland-support-to-aval...
| MikeCodesDotNET wrote:
| We're actively working on Wayland support for Avalonia 12.
| While we considered dual licensing it, we ultimately decided
| to keep things simple and make it MIT licensed.
| zamalek wrote:
| > [Article] What works in GNOME might not work in KDE. What
| works in both might not work in Sway.
|
| If you subtract GNOME from the set then things become a lot
| more sane. "Compositor-specific extensions" are really
| "everyone besides GNOME extensions." The system tray
| extension _isn 't_ KDE-specific. Sure, window positions
| might not be available at all (because they don't make
| sense for a TWM), or a user might not have a system tray
| bar (or you might be on GNOME). However, if they did have a
| system tray it would be the StatusNotifierItem protocol.
| Ideally, these should be handled like other platform
| features like accelerometers etc.. That may not be
| possible, either way a lot of them can safely noop.
|
| > [Article] For Avalonia, this means "Wayland support"
| isn't one implementation, it's potentially dozens. We're
| not just writing a Wayland backend; we're writing a GNOME-
| Wayland backend, a KDE-Wayland backend, a Sway-Wayland
| backend,
|
| If you're making per-WM backends then you've fundamentally
| misunderstood how extensions are supposed to work. Other
| Wayland client libraries do not have a independent backends
| for KDE, Sway, and GNOME. Maybe quirks would be needed
| because you're attempting to support an existing UI library
| - but those should be few and far between.
|
| IIRC Avalonia supports Vulkan as a rendering backend?
| Wayland protocols are the same line of thinking as Vulkan
| extensions.
|
| wlroot and smithay are good examples of what extensions are
| used in the real world.
| soumyaskartha wrote:
| Microsoft adding Linux support for yet another framework nobody
| asked for while WinForms still exists in 2026 is very on brand.
| louhike wrote:
| Avalonia is not made by Microsoft and is often considered as
| one of the best way to make desktop app with .NET.
| Pay08 wrote:
| I can understand the confusion, Microsoft also has a
| framework called MAUI.
| pie_flavor wrote:
| The Microsoft MAUI framework is the one being brought to
| Linux by Avalonia, yes.
| LeFantome wrote:
| The MAUI they are talking about is the Microsoft framework
| you are referencing.
|
| MAUI is Open Source but Microsoft does not provide a Linux
| back-end. This is a non-Microsoft effort to bring Linux
| support to MAUI.
| tonyedwardspz wrote:
| Excited for this. I do wonder how much effort it will be to get
| an existing app working with this.
| general1465 wrote:
| What is unclear to me, is how does it work with Avalonia pricing
| wise? If I am having commercial application for Windows, Android,
| MacOS, iOS (Microsoft MAUI range) then according to [1] I would
| need to dish out 125000 EUR per application. But it was never
| clear to me what are the conditions which actually triggers the
| difference between free and paid plan.
|
| [1] https://avaloniaui.net/xpf/pricing
| Kwpolska wrote:
| Avalonia is free and open-source. Avalonia MAUI currently
| appears to be MIT as well [0]. The pricing you've linked to is
| pricing for their paid offering, which wraps Avalonia and a
| WPF-style API for easy migration of legacy apps.
|
| [0]
| https://github.com/AvaloniaUI/Avalonia.Controls.Maui/blob/ma...
| exceptione wrote:
| Let me rephrase what sibling said: the paid offering is for you
| when you have gotten an existing traditional windows-only wpf
| application and you want to have that appplication cross-
| platform _as-is_ , foregoing any effort to port it to
| AvaloniaUI.
|
| You won't need the paid offering if you build your stuff in
| AvaloniaUI directly.
| oblio wrote:
| How mature is Avalonia for an universal app? Big 3 desktop
| plus big 2 mobile?
| exceptione wrote:
| I can't comment on that specifically, but it works with
| MVVM extensions toolkit, which is handy for decoupling of
| event handling and is helpful in complex scenario's.
|
| Most import thing to look for are the components you need
| imho. You can build themselves, but if you can use
| something ready made, that helps of course. You would best
| take look at their gallery to see if you see something
| similar for your needs.
| politelemon wrote:
| I like the possibilities this opens up but I'm struggling to
| understand how wasm is involved. I had the impression it doesn't
| have a user interface, but it's called by javascript instead.
| CodesInChaos wrote:
| https://avaloniaui.net/platforms/wasm
|
| > Avalonia renders through Skia compiled to WebAssembly
|
| I'd guess it builds on Skia CanvasKit and renders to an HTML
| Canvas element.
|
| https://skia.org/docs/user/modules/canvaskit/
| pjmlp wrote:
| The rewrite from Xamarin.Forms into MAUI, has given a bad taste
| to many in the community, and kudos to Avalonia to make it happen
| on GNU/Linux.
|
| By the way on macOS MAUI uses Catalyst as backend, not native
| macOS APIs.
|
| Also it is kind of interesting that Miguel de Icaza, nowadays
| completely switched into Swift ecosystem, and is the responsible
| for making game development on iPad with Godot a reality. Or
| porting old .NET ideas of his into Swift.
| exceptione wrote:
| From a quick look, I can't find a reason. _why?_ Even MS doesn 't
| fully believe in Maui, as it seems they reblessed WPF. For
| Avalonia to do the work of MS seems weird, their own free regular
| WPF-like Avalonia UI toolkit is already the standard for cross
| desktop development.
|
| I was looking for the line: Microsoft sponsored us. Even then I
| would not understand why they would spend effort on a doomed
| project. I know Avalonia being a small company has a big task
| ahead of porting Avalonia UI to Wayland, which makes porting MS
| semi-abandonware all the more confusing.
|
| But since these people aren't idiots, I gladly assume I am
| missing something.
| nobodyandproud wrote:
| > But since these people aren't idiots, I gladly assume I am
| missing something.
|
| Microsoft politics. Someone who's aware please confirm but I
| want to say it's something like...
|
| Different orgs jockey for power and you can see when the wrong
| orgs and initiatives influence different products.
|
| What I can't tell is whether it's established teams scrambling
| to stay relevant. Or if it's new teams and products imposing
| their influence where they shouldn't.
|
| But the Windows team doesn't want to see Linux get traction, so
| they'll do their part to hamper any OS shims or any native-
| first functions in Office.
|
| The Office org wants to expand beyond Windows but for political
| reasons, the only add-in tech without platform lock-in is JS so
| they ally with the Azure/Cloud team to allow third parties to
| create add-ins.
|
| Because of this partnership, rather than making a streamlined
| add-in store, publishers are required to learn the full
| complexities of Entra and the Partner centers.
|
| I imagine the UX and .NET orgs are caught in similar political
| battles; but without any direct income or product to influence.
|
| If I had to guess, they were in the Windows team at one point;
| but with the platform-independent initiatives (good) it's been
| a shitshow over the past 20+ years for desktop developers
| (bad).
| exceptione wrote:
| I agree that MS has often internal conflicts of interest. But
| that still leaves su with the question: why would Avalalonia
| do the work that MS did not bother to do, where is the
| benefit? I mean, Avalonia has AvaloniaUI already.
| siwatanejo wrote:
| > Even MS doesn't fully believe in Maui
|
| Source: I made it up.
| nobodyandproud wrote:
| How many MS products are dog fooding Maui?
|
| When COM rolled out, every product was very much on board.
|
| The need for Maui in-house is for...what?
| skeeter2020 wrote:
| doesn't look like much; the seem to use electron for almost
| everything in this space. If they had faith in Maui
| something (VS Code, Teams, Outlook, ... calculator?) would
| use it.
| exceptione wrote:
| MS has multiple personalities, so some might do, I will give
| you that. Meanwhile, WPF is getting rehabilitated. It seems
| like that not only the average developer has concluded that
| all the other UI frameworks since wpf are half-baked. Someone
| more involved than me makes the same assessment:
| https://news.ycombinator.com/item?id=47480056
|
| I recommend everyone to ignore all experiments, and go
| straight for AvaloniaUI, as it is quite similar to wpf,
| actively devloped and cross-platform. The only downside I see
| is that Wayland is still in progress yet.
| cjbgkagh wrote:
| Some of us have insider connections
| array_key_first wrote:
| MS doesn't believe in any of their toolkits, and the source
| is their actions. First off, they're addicting to introducing
| new toolkits instead of improving existing ones. But that
| doesn't even matter, because they just use Electron anyway.
| corstian wrote:
| Between MAUI and Avalonia, Avalonia is the superior framework
| when it comes to technical quality as well as community
| response. What Avalonia doesn't have is the enterprise
| component libraries MAUI has. As part of this move Avalonia is
| about to reel in these libraries, as well as a whole bunch of
| MAUI teams.
|
| In other words; Avalonia is coming for MAUIs turf.
| blendergeek wrote:
| Just a reminder that this MAUI has nothing to do with the pre-
| existing cross platform UI framework MauiKit from MAUI Project.
|
| https://mauikit.org/
| userbinator wrote:
| Nor MediaTek's UI framework:
| https://lpcwiki.miraheze.org/wiki/MediaTek_MAUI
| robin_reala wrote:
| _Accessibility bridging between .NET MAUI and Avalonia is
| currently limited._
|
| Nowhere near production ready, got it.
| siwatanejo wrote:
| Almost nobody needs accessibility; let's be realistic, it's
| obviously not a priority. The priority is to put this out the
| door (MVP style).
| saidnooneever wrote:
| this was down voted but its correct. even if as a human j
| disagree and it sounds mean, this is how people think in
| general..too bad, but too true. accessibility will come after
| 'launch'.
| skeeter2020 wrote:
| If they mean "only a small subset of your users need
| accessibility support" this might be true, but I haven't
| worked for a organization selling software in the past 20+
| years that hasn't needed to provide support, and those orgs
| are the audience for a .net cross-platform UI solution, so
| in that case they are wrong; almost everyone "needs
| accessibility support".
| saidnooneever wrote:
| provide support on a product and accessibility are really
| different things.
|
| accessibility is like implementing braille and things for
| deaf and colourblind etc.
|
| support is resetting password and helping with accounts
| etc.
|
| so one is to get a certain category of users to be able
| to access your site in the general sense. the other
| (support) is about helping people who already can access
| your site or service.
| tacticus wrote:
| > accessibility is like implementing braille and things
| for deaf and colourblind etc.
|
| or
|
| - larger fonts
|
| - Better contrast controls,
|
| - Non abstract art iconography,
|
| - larger buttons and keyboard navigation,
|
| - understanding that there are many types of
| colourblindness with different requriements,
|
| - the ability to set lightmode on your app and website
| due to the issues reading text for anyone with
| astigmatisms,
|
| - reducing the amount of animation or motion blur
|
| The range of what accessibility is isn't small and some
| of it is going to be required for the vast majority of
| products. Also accessibility requirements change over
| time. eyes and hearing degrade. the desire to waste
| energy trying to find some stylish button that has no
| border and almost no contrast to indicate where it is
| goes away
| skeeter2020 wrote:
| Unfortunately too many developers share your perspective. I'd
| be surprised if anyone building commercial software would
| move ahead without accessibility support though because, 1.
| it's required by law in many situations, and 2. it makes good
| business sense.
| MikeCodesDotNET wrote:
| This is the first preview release. It's targeting a preview of
| .NET 11, which should help you understand that it's not
| intended to be used in production right now.
|
| We don't expect this to graduate from a preview until November.
| There's plenty of time to sort out Accessibility.
| zteppenwolf wrote:
| Why would anyone want .NET on Linux?
| dardeaup wrote:
| My guess would be so that they could make use of a single code
| base.
| orthoxerox wrote:
| Orgs that have their LOB software written in .NET and want to
| migrate to Linux without rewriting it. Avalonia's commercial
| offering is designed to do exactly that.
| drzaiusx11 wrote:
| C# is cross platform, I'd bet money that most .Net services run
| on Linux these days (Azure runs more Linux VMs than Windows VMs
| after all) This just fills the client side gap so you can unify
| the full stack under one language a la node etc
| jeremycarter wrote:
| Hundreds of thousands of .NET applications run inside Linux
| Docker containers.
| giancarlostoro wrote:
| Nice, I love MAUI but hate that it has no support for Linux. The
| only option I have is Avalonia and Photino. I love .NET but when
| I want to make a GUI I reach for other languages because
| Microsoft despite reinventing their .NET GUI stack every few
| years, they never add Linux support. Personally I prefer to use
| their built-in stuff as much as possible.
| Rohansi wrote:
| > Personally I prefer to use their built-in stuff as much as
| possible.
|
| Why? Avalonia is a spiritual successor to WPF but FOSS and
| cross-platform.
| ChicagoDave wrote:
| I've been using Claude to build native versions of a couple of
| apps and what was once unthinkable (maintaining multiple code
| bases) is now fairly trivial. And Electron/Tauri implementations
| are high quality.
|
| I'm not sure platforms like Maui are necessary anymore.
|
| I did note the comment "if you don't want Liquid Glass" as a
| direct response to GenAI native development.
|
| Time will tell.
___________________________________________________________________
(page generated 2026-03-22 23:00 UTC)