Cross platform WPF

I am working on a project with a non-trivial WPF desktop application. Currently it is Windows only (obviously) but we have a desire to run on Linux and OSX.

We have recently been talking about plans to transition our client to a UI technology that does have xplat support and then this popped up on my radar. It would save us a LOT of time and effort if WPF could be run on other desktop platforms. Even if there were some limitations it would still be a big win for us.

So my question is, are there plans to implement a compatible version of WPF now? If so could someone describe the high level timeline and perhaps any obvious gotchas to someone in my position?

Thanks! Exciting times…


While I can speak for sure to my knowledge there is no plan to port WPF to other platforms. The main reason is the WPF is really just an abstraction of Win32 APIs and DirectX so a port would either need to emulate those two or make something WPF like but fitting for the platform. If you really want cross platform WPF like stuff you could try, which is built on top of MonoGame so is extremely cross-platform but also very limited.

I’ve been working on an open-source implementation of WPF at Not done much work on it recently because of too much proper work and lack of enthusiasm, but it might interest someone. Still Windows-only ATM but a cairo renderer wouldn’t be impossible I don’t think.

You may want to check out this project too:

Okay, so I’ve signed up just to give my 2 cents on this. I’m not a .net dev. But so far whenever I pulled some C# off github to run on my sweet, sweet linux box it ran just fine with mono!
Except you know those corner cases that used (a bit of) WPF. I realize that I’m replying here as a complete outsider that doesn’t know what he’s talking about, but mono was always enough for me. .net will always remain a windows only API riddled platform for me until i can run such apps on linux, there are quite a few .net features I would really like to get my hands on, such as LINQ. But if it doesn’t run everything on linux it’s just a no-go for me, sorry. Java does at least have Swing and AWT (which I both absolutely hate) but I think something must be done here for .net to become truly cross-platform and interesting for developers.

I hope this small rant isn’t too much in the wrong spot and maybe seen by the right people :‬)

Another option to look at is Eto.Forms. It is an abstraction layer over Windows Forms, WPF, MonoMac/Xamarin.Mac, and Gtk. It also has a Direct2D implementation on Windows for super fast graphics, and has a full set of 40+ controls available on all platforms with MVVM binding support.


Or you can also try Xwt, used by Xamarin Studio/MonoDevelop:


Thanks everyone. This is about what I was expecting you to say, I just wanted to double check.

Hadn’t heard of Eto.Forms before. How does Eto.Forms compare with Xwt?

It is very similar in how it works, but is (imo) more mature as it has been around longer - hence the WinForms platform. Also, all controls and graphics functionality have been tested on all platforms and are all extremely functional. There is also (rudimentary) support for loading UI definitions in xaml or json.

That’s interesting. I had a discussion on Twitter about the possibility of a Xamarin.Forms like solution that would target both WPF and Xamarin.Mac. Xwt seems to be more like Windows Forms and also renders using Gtk# and I think the goals of cross platform (and OSS) WPF would probably be

  1. XAML
  2. Designer support
  3. Native look and feel
  4. WPF is already established

And maybe a modification of Xwt is the answer to include support for a markup language. Which I don’t see right now. But I didn’t know about Xwt until I read this post so it needs to be marketed more :smile:

WPF is very strongly hardware bound through DirectX, so this backend will be a problem. WPF as open source would/will help a lot as it would fro other side (native c++). Check what c++ team (the last one sadly) had to say on Qs about OpenGL - “after last few days nothing is excluded” (Anno Domini 2014-11-12)

1 Like

To port WPF to MONO is great idea. I’m just dreaming about that. Anyway, it’s a lot of work to implement this framework in cross-platform way, since the current Microsoft’s implementation is tightly coupled with Windows and DirectX. On my first look of the problem, there are two main tasks. First, create independence from concrete windows system. Second is to create plugable backends for Visual/DUCE rendering system of WPF. I’ll be very glad to work on it, but who will invest to that project?

I already posted this in other topic, but :smile:

I created XAML UI for MonoGame/SunBurn, which is based on WPF -

Check that out and let me know what you think

1 Like

Which of these options would be most performant?
It needs to have virtualization, bindings and datatemplates.

Abstracting away the Win32 dependencies and rendering/composition engine and implementing cross-platform implementations is far from the whole battle. Many WPF applications ship with at least some third-party components, and many of those also rely on p/invoke and Win32 APIs. Working out the platform-specific bugs and eccentricities across WPF and the major third-party components would likely be a years-long effort, and by that time Microsoft may very well be pushing an entirely new UI stack.

And implementing cross-platform rendering/composition layers isn’t as straightforward as most people think. One of the bigger hiccups would be achieving consistency in text layout and rendering across all platforms. WPF supports both GDI-compatible layout and “ideal” layout complete with bidirectional antialiasing and subpixel positioning. I believe, at the moment, both layout modes are delegated to DirectWrite, which is not open source, and is unlikely to become open source, and thus porting the behavior would be far more difficult.


No one is asking for them to do the third party component’s job, and a lot of third parties are purely managed no p invoke and would work pretty much as is.

None of what you mention seems like a huge task and losing some accuracy in text doesn’t seem like a huge tradeoff compared to not having wpf at all and using an alternative. Yes directwrite would be missed but you can still very much work through that and it’s actually an upside (another thing that isn’t done by the OS directly / part of win32, so another thing that just requires redoing on the graphic stack and not porting Platform specific code).

Compared to the benefit the cost of porting WPF seems very minor, it could be a 1 man project over a few months, 6 at most based on what i can see (not talking about porting it to a specific platform, but about porting it to pure managed + supporting rendering engine switching).

1 Like

It feels to me Microsoft is slowing down WPF development and it will end up abandoned. If it is one man project it is easy: crowdfunding. Otherwise, commercial product or open source collaboration.
Imagine Mantle becomes open standard, nvidia accepts it, and we have it (or other low level rendering API) under WPF instead of DX

1 Like

Some of those alternate libraries people are linking to are interesting but the problem I have is that I have an existing WPF application and switching to one of those alternate libraries will be a significant rewrite. And to be honest, if it comes to a rewrite I’m strongly leaning towards using javascript / html, using something like CEF instead. If there was a WPF port effort instead on the other hand… that would be pretty interesting. I wouldn’t even have to be perfect, just good enough.

Yes but that’s your specific use case problem, it would still be very usefull for a very large number of us who want to port existing project or create new project, on wpf, on new platforms, even if it means some third party libraries are out (do you have any in mind? I use Telerik controls and i don’t think they’re doing much Windows specific except maybe in their custom window?).

.NET Foundation Website | Blog | Projects | Code of Conduct