Ask HN: Are you using .NET to write cross-platform desktop or mobile apps?
88 comments
You might want to consider how much Microsoft uses it in their own products before choosing to use it. This article describes the situation pretty well:
"not even Microsoft, literally the people who own Xamarin, use it in any of their big products like Teams, Outlook, and the list goes on. Instead, they reach for native development or Electron. So we can just tie a bow in it and have a minute's silence for another end-of-life cross-platform software development framework."
"None of These Problems Are Solved With MAUI. The poor developer experience, how apps look, XAML being a pain, and these other core issues won’t be resolved by MAUI. So, if you already know Xamarin Forms, and you’re waiting for MAUI to land, but you’re not 100% thrilled with the experience so far, then it’s a great opportunity to think about learning something else."
Source: https://betterprogramming.pub/xamarin-forms-is-dying-and-mau...
"not even Microsoft, literally the people who own Xamarin, use it in any of their big products like Teams, Outlook, and the list goes on. Instead, they reach for native development or Electron. So we can just tie a bow in it and have a minute's silence for another end-of-life cross-platform software development framework."
"None of These Problems Are Solved With MAUI. The poor developer experience, how apps look, XAML being a pain, and these other core issues won’t be resolved by MAUI. So, if you already know Xamarin Forms, and you’re waiting for MAUI to land, but you’re not 100% thrilled with the experience so far, then it’s a great opportunity to think about learning something else."
Source: https://betterprogramming.pub/xamarin-forms-is-dying-and-mau...
In the case of Teams, I think they regret choosing Electron.
A Xamarin app doesn't need to use XML or Xamarin Forms which provides UI components. A totally custom interface/game can be developed with Xamarin + SkiaSharp which provides drawing primitives.
A Xamarin app doesn't need to use XML or Xamarin Forms which provides UI components. A totally custom interface/game can be developed with Xamarin + SkiaSharp which provides drawing primitives.
As a user with a finite amount of memory on my computer, I also regret them choosing Electron.
They should hire better engineers, perhaps those with more experience than just leet code. The apps i built using electron for some clients have none of the issues teams has. I mean come on, teams is a basic chat app, how difficult is it to optimise it?
(bit of self-promotion)
They do have a React version on WebView2 that is (supposedly) much better, but it's only for personal accounts right now, though that could change [1].
Thankfully their internal API is fairly self-documenting, so I've been looking into creating my own Teams client if you're interested [2]. We'll see if it'll have been an effort in vain depending on how well Microsoft Teams 2.0 goes.
[1] https://www.techradar.com/news/a-new-generation-of-microsoft...
[2] https://blog.opercom.co.uk/posts/news-13-08-22/
They do have a React version on WebView2 that is (supposedly) much better, but it's only for personal accounts right now, though that could change [1].
Thankfully their internal API is fairly self-documenting, so I've been looking into creating my own Teams client if you're interested [2]. We'll see if it'll have been an effort in vain depending on how well Microsoft Teams 2.0 goes.
[1] https://www.techradar.com/news/a-new-generation-of-microsoft...
[2] https://blog.opercom.co.uk/posts/news-13-08-22/
“so I've been looking into creating my own Teams client if you're interested”
thanks for the link, looks good. styling and eye candy can be added later. first i think it just needs to be optimised for low memory and speed - not using react is a good step in this direction.
thanks for the link, looks good. styling and eye candy can be added later. first i think it just needs to be optimised for low memory and speed - not using react is a good step in this direction.
I agree that the client's performance is important. I'm hoping to avoid frameworks so that any issues will be as clear as possible, but maintenance will tell if that's a good decision.
Maintenance may be pita but the issue with using web specific ui frameworks for a desktop electron app is that web frameworks arent meant to be run for a long time. They take a lot of memory. One has to find the right balance between what to do in the renderer process (ideally nothing more but really basic css and js, maybe a web worker or two), and everything else in the main process.
I threat the main process as a backend api and use ipc as a broker between that and the ui. The renderer process does nothing but show text and icons. From that point on one can have fun with threads and all :-)
I threat the main process as a backend api and use ipc as a broker between that and the ui. The renderer process does nothing but show text and icons. From that point on one can have fun with threads and all :-)
Teams is integrated with lots of other products such as AD, O365... It's far from a "basic chat app".
I am sure the app you wrote does not have millions of users daily, either.
"I am sure the app you wrote does not have millions of users daily, either"
This argument is weak. Its not like millions of people are crammed within the app all at the same time, while integrated with AD, or other microsoft bloatware. It may impress inexperienced devs, but it's really not much of an architectural challenge. MS could have done a better job.
But to satisfy your curiosity, my background is in developing some rather large systems, used by hundreds of millions. Not these apps specifically (although they do handle large amounts of data, a lot more than teams), and it's a good indicator that I know what I am talking about and without bragging I can smell poor design and a lazy job.
This argument is weak. Its not like millions of people are crammed within the app all at the same time, while integrated with AD, or other microsoft bloatware. It may impress inexperienced devs, but it's really not much of an architectural challenge. MS could have done a better job.
But to satisfy your curiosity, my background is in developing some rather large systems, used by hundreds of millions. Not these apps specifically (although they do handle large amounts of data, a lot more than teams), and it's a good indicator that I know what I am talking about and without bragging I can smell poor design and a lazy job.
AD is bloatware? O365 is?
I think the only inflated thing here is your ego.
I think the only inflated thing here is your ego.
I dont think you should be taking this personal. But yes, both are bloatware.
I don't think you should be talking about things you don't know or understand.
These products have an audience because microsoft speaks management. My advice for them is to git gud and move on.
[deleted]
I know Teams gets a lot of hate on here. Perhaps I am a special exception, but I just don’t see it. Of course I don’t expect much from it, but it’s definitely not the worst chat client I have used. Granted I am using it on MacOS, iOS, and iPadOS, so maybe the hate is not on those platforms.
Yes, it's a "basic" chat app. Like google is a "basic" search engine, how hard can it be to make something like that? Just make it go search?
Comparing teams to google is a bit meh. There’s nothing special about that app other than how crap it is. A poorly written tool made by inexperienced devs.
Teams is also very bloated (or "full featured" depending on how you want to spin it) compared to other chat apps, which does make it special by comparison.
Teams is trying very hard to make itself a platform, and it supports telephony in a way that other chat apps don't. I can be reached on my work Teams account via a dedicated phone number, and the account includes a bunch of Viva applications and pretty deep integrations with Office, SharePoint, and Power Platform.
Teams is trying very hard to make itself a platform, and it supports telephony in a way that other chat apps don't. I can be reached on my work Teams account via a dedicated phone number, and the account includes a bunch of Viva applications and pretty deep integrations with Office, SharePoint, and Power Platform.
First indicator that teams is ill designed is feature creep. But i suppose people find some utility in it. Telephony is likely handled by a server and teams is acting as a video / voice client just like any other modern chat app. I dont know about its integration with office and other microsoft bloatware but i do imagine those integrations are poorly designed as well. Microsoft products are well known for taking up memory for no good reason so i dont see why this would be an exception. Blaming issues on electron is just lazy on their part.
I’m not sure I’ve heard the Teams folks explicitly blaming Electron. I run other, more complex MSFT programs (eg Office) on the same computer, and they use a fraction of the memory and CPU that Teams does.
They could also just use flutter which is skia under the hood - I think would be substantially faster than dealing with Xamarin.
Doing stuff with Skia on MAUI at least is tricky because there is no concept of a mouse, so good luck creating a hover effect on your button.
https://github.com/dotnet/maui/issues/3739
Doing stuff with Skia on MAUI at least is tricky because there is no concept of a mouse, so good luck creating a hover effect on your button.
https://github.com/dotnet/maui/issues/3739
Those products predate the purchase of Xamarin and are web products in their latest form. It's not that surprising or telling.
None of those products, as apps, predate Xamarin. Outlook for Mobile was an acquisition; Xamarin existed at the time.
Teams Mobile apps are native and built while Xamarin existed; not using Xamarin.
Teams Mobile apps are native and built while Xamarin existed; not using Xamarin.
Xamarin existing and MS touching it are different things, though. It's only been "official" for a short time and only after Microsoft acquired it.
Rewriting the history as if Xamarin was an option from the beginning is disingenuous.
Rewriting the history as if Xamarin was an option from the beginning is disingenuous.
Microsoft acquired Xamarin on Feb 24, 2016
https://en.wikipedia.org/wiki/Xamarin
Microsoft announced Teams March 17, 2017, with a launch date of the end of 2018 https://news.microsoft.com/announcement/teams-platform-intro...
Make of that what you will.
Microsoft announced Teams March 17, 2017, with a launch date of the end of 2018 https://news.microsoft.com/announcement/teams-platform-intro...
Make of that what you will.
Which applications have Microsoft chosen to build with Xamarin?
So the same story as with MFC.
At a previous agency job, I was on a project that was re-writing an iOS and Android app used by millions of people. We looked hard into using Xamarin for this but in the end concluded that it was not ready yet. This was in 2019.
Main reasons were:
- You can use Xamarin.Forms to write cross-platform UI, but our UI was complicated enough (a weather app with lots of custom UI) that Xamarin.Forms would not have worked for us. So we still needed to write 2 separate UI codes, which Xamarin allows for because it exposes the complete SDKs for both platforms via Xamarin.iOS and Xamarin.Android.
- Xamarin provides a way to use existing 3rd party libs written in native iOS/Android by creating "bindings". For very popular libs, the Xamarin team maintains these bindings, for others, you need to rely on open source ones. The client required us to use a bunch of third party libraries and we either couldn't find them at all, or found ones that didn't work. We needed Mapbox, Firebase analytics & Crashlytics, and some other ones... pretty well-known libraries.
We were in contact with someone at Microsoft during this exploration and even they couldn't help us. They couldn't point us to any big well-known names using Xamarin and they couldn't help us with any of the missing or broken bindings we needed.
Thankfully in the end we just split up into 2 teams and wrote the app in native iOS and Android.
Main reasons were:
- You can use Xamarin.Forms to write cross-platform UI, but our UI was complicated enough (a weather app with lots of custom UI) that Xamarin.Forms would not have worked for us. So we still needed to write 2 separate UI codes, which Xamarin allows for because it exposes the complete SDKs for both platforms via Xamarin.iOS and Xamarin.Android.
- Xamarin provides a way to use existing 3rd party libs written in native iOS/Android by creating "bindings". For very popular libs, the Xamarin team maintains these bindings, for others, you need to rely on open source ones. The client required us to use a bunch of third party libraries and we either couldn't find them at all, or found ones that didn't work. We needed Mapbox, Firebase analytics & Crashlytics, and some other ones... pretty well-known libraries.
We were in contact with someone at Microsoft during this exploration and even they couldn't help us. They couldn't point us to any big well-known names using Xamarin and they couldn't help us with any of the missing or broken bindings we needed.
Thankfully in the end we just split up into 2 teams and wrote the app in native iOS and Android.
> Thankfully in the end we just split up into 2 teams and wrote the app in native iOS and Android.
When you have millions of users, that's definitely the right call.
When you have millions of users, that's definitely the right call.
Did you consider writing the bindings yourself? In my experience when I've needed a few dozen APIs, it wasn't too bad. It certainly seemed like less work than two native apps. But perhaps that wasn't the case for you?
Microsoft stopped development (more or less) around May 2020 to focus on MAUI, which was released in November 2020.
Actually it wasn’t - MAUI wasn’t released until May 2022, tooling was just released July 2022 for Windows, and VS for Mac with proper support has yet to be released. If you’re used to command line that may not seem like a big deal, but the whole point of the .NET ecosystem is that you have a rich set of tools that saves time and enhances developer productivity.
So as for why Xamarin wasn’t discussed for the last few years, it’s probably because Microsoft put it in a coma for 2 years.
I was hoping MAUI would fix a lot of the quality issues, but like any big rewrite, it seems to have traded one set of problems for another. The developer experience is better, but there are lots of bugs in basic functionality that make it difficult to use. https://github.com/dotnet/maui/labels/t%2Fbug I don’t think Microsoft has enough engineers assigned to this project to make it successful.
If you don’t care about the quality of your app (e.g. your a corporate form developer and don’t care about your users) MAUI is a great choice. But if you don’t care about the UX, web technologies are almost certainly a better choice.
As for native desktop, you’d have to be really stupid to choose WinUI or UWP, unless the point of the app is to be a WinUI or UWP demo. WPF is fine, but then why on earth would you choose that over electron or WebView2, which solves some of the resource problems from pure electron.
All of this is coming from someone whose entire career is built on .NET client technology… I was really hoping (and still hope) for a turnaround. I bet big on Xamarin being the right approach; I still think it is, but Microsoft really dropped the ball since the acquisition.
Actually it wasn’t - MAUI wasn’t released until May 2022, tooling was just released July 2022 for Windows, and VS for Mac with proper support has yet to be released. If you’re used to command line that may not seem like a big deal, but the whole point of the .NET ecosystem is that you have a rich set of tools that saves time and enhances developer productivity.
So as for why Xamarin wasn’t discussed for the last few years, it’s probably because Microsoft put it in a coma for 2 years.
I was hoping MAUI would fix a lot of the quality issues, but like any big rewrite, it seems to have traded one set of problems for another. The developer experience is better, but there are lots of bugs in basic functionality that make it difficult to use. https://github.com/dotnet/maui/labels/t%2Fbug I don’t think Microsoft has enough engineers assigned to this project to make it successful.
If you don’t care about the quality of your app (e.g. your a corporate form developer and don’t care about your users) MAUI is a great choice. But if you don’t care about the UX, web technologies are almost certainly a better choice.
As for native desktop, you’d have to be really stupid to choose WinUI or UWP, unless the point of the app is to be a WinUI or UWP demo. WPF is fine, but then why on earth would you choose that over electron or WebView2, which solves some of the resource problems from pure electron.
All of this is coming from someone whose entire career is built on .NET client technology… I was really hoping (and still hope) for a turnaround. I bet big on Xamarin being the right approach; I still think it is, but Microsoft really dropped the ball since the acquisition.
I continue developing most apps with WPF mostly because they are OS-dependent productivity tools, and target Windows.
For the cross-platform stuff (mostly deep learning demos with UI) I use Avalonia because it supports Linux.
For the cross-platform stuff (mostly deep learning demos with UI) I use Avalonia because it supports Linux.
What’s your opinion on WinForms? I’ve yet to come across anything that’s better in terms of perf, developer experience and stability.
WinForms is fine but there are issues with support for things like high DPI. Maybe that’s fixed now. I wouldn’t use it except for a very small utility, but nowadays I just use python scripts for small utilities.
Based on the .NET Rocks podcast, it sounds like Blazor is the new WinForms.
Given the situation with Windows, I don’t see it being a great choice for a monoplatform app (unless that app is a game) - chrome books and Mac are getting more popular, and web works everywhere.
Based on the .NET Rocks podcast, it sounds like Blazor is the new WinForms.
Given the situation with Windows, I don’t see it being a great choice for a monoplatform app (unless that app is a game) - chrome books and Mac are getting more popular, and web works everywhere.
We built Rec Room (https://recroom.com/) using Unity across several platforms:
* iOS
* Android
* PC
* PlayStation
* Xbox
* VR
Rec Room is a "game for building games". I'd say Unity has worked pretty well. Given that the product is a game this success with single-lang cross platform may be more common than other industries. Still, though, I'm surprised that there isn't a similar "engine" for non-game cross platform development like Unity or Unreal that folks are generally happy with.
(Shameless plug, we are hiring if folks are interested https://recroom.com/careers)
* iOS
* Android
* PC
* PlayStation
* Xbox
* VR
Rec Room is a "game for building games". I'd say Unity has worked pretty well. Given that the product is a game this success with single-lang cross platform may be more common than other industries. Still, though, I'm surprised that there isn't a similar "engine" for non-game cross platform development like Unity or Unreal that folks are generally happy with.
(Shameless plug, we are hiring if folks are interested https://recroom.com/careers)
Funny enough, I have seen some people use Unity to develop basic cross platform applications rather than games.
I just commented someplace else that I’m using Godot to achieve exactly that. Much smaller and nimbler than Unity, too.
For cross platform framework. I would recommend Avalonia https://avaloniaui.net/
It has the flexibility and cleaner version of WPF but also lets you build it all in code if you choose like Flutter. They have a support business to support the project. So you know it will be well supported for years to come. The team is very responsive to the community also.
If I was Microsoft I would just fork Flutter and add C# support and call it a day. Flutter is really flexible for mobile and desktop and has a ton of community support with libraries.
If I was Microsoft I would just fork Flutter and add C# support and call it a day. Flutter is really flexible for mobile and desktop and has a ton of community support with libraries.
I recently spoke with the tech lead of a team that is all in on .NET for web development, as well as using Xamarin.Forms to develop cross-platform mobile apps. While this achieved their goals, the lead felt that the complexity of dealing with platform-specific edge cases slowed them down enough that developing using native tooling would have taken the same amount of time. He would not choose Xamarin again if faced with the same choice.
This and other stories reinforces my belief that Kolmogorov complexity in software is a real thing(tm) and cross-platform GUI tooling will never be good enough to avoid having to write platform-specific code.
Issue with Xamarin.Forms was that provided widgets were quite lackluster and to write custom widgets you had to know native APIs of multiple platforms.
IMO, the source of the problem was that it's widgets used native widgets for rendering. Build-in widgets were lowest common denominator, primarily supporting only features avaliable on all platforms. Where platforms deviated, complexity started.
However, UI frameworks that render widgets themselves, using drawing APIs, are a completely different story. They are harder to create, as they need to develop all widgets from scratch (rendering, text, input, accessibility etc). Basically reimplementing part of OS APIs. But once this is complete, the hard part is done and supporting additional platforms is relatively simple. Avalonia has written good blog post about this: https://dev.to/avalonia/avalonia-platform-support-why-its-si...
Developing cross-platform GUI application with this kind of frameworks is about as complex as developing GUI application using native SDK for a single platform. Most complexity doesn't result from different platforms anymore, but from different form factors and input devices.
They have one Achilles' heel however. The web. HTML is unfortunately much higher level that drawing API on other platforms. So, the only option for the web is usually WebAssembly.
IMO, the source of the problem was that it's widgets used native widgets for rendering. Build-in widgets were lowest common denominator, primarily supporting only features avaliable on all platforms. Where platforms deviated, complexity started.
However, UI frameworks that render widgets themselves, using drawing APIs, are a completely different story. They are harder to create, as they need to develop all widgets from scratch (rendering, text, input, accessibility etc). Basically reimplementing part of OS APIs. But once this is complete, the hard part is done and supporting additional platforms is relatively simple. Avalonia has written good blog post about this: https://dev.to/avalonia/avalonia-platform-support-why-its-si...
Developing cross-platform GUI application with this kind of frameworks is about as complex as developing GUI application using native SDK for a single platform. Most complexity doesn't result from different platforms anymore, but from different form factors and input devices.
They have one Achilles' heel however. The web. HTML is unfortunately much higher level that drawing API on other platforms. So, the only option for the web is usually WebAssembly.
I love C#.NET + Xamarin + Visual Studio.
* Easy to get started
* Builds for iOS on a remote Mac but runs in local emulator
* Performant!
* Simple to write device specific code
* Power of .NET
* Supports more than Android and iOS, like desktop UWPWe are on top of .NET 6 today. Been using a .NET stack for over half a decade in production.
We still just do the web app thing. For our business & customers, this is the lowest-friction way to deliver the application experience. So, we are effectively cross platform on both our client and server. We only have to maintain one code pile to make it all happen.
If you can figure out a way to make the web work for you, try it. Having an app icon on someone's phone is such a ridiculously wasteful thing to chase unless you can properly justify it.
We still just do the web app thing. For our business & customers, this is the lowest-friction way to deliver the application experience. So, we are effectively cross platform on both our client and server. We only have to maintain one code pile to make it all happen.
If you can figure out a way to make the web work for you, try it. Having an app icon on someone's phone is such a ridiculously wasteful thing to chase unless you can properly justify it.
You can still build a simple webview wrapper and put it to the App Store.
Not really. See 4.2. https://developer.apple.com/app-store/review/guidelines/#min...
Nothing to see.
Webview apps are still being accepted by the App Store. They don't care what tech you use to build your app, as long as it provides functionality.
Webview apps are still being accepted by the App Store. They don't care what tech you use to build your app, as long as it provides functionality.
If it is „app like“ that’s enough for the App Store. It can’t be just a browser for a desktop website for example.
It’s all about functionality and UX, not about technology.
It’s all about functionality and UX, not about technology.
I initially developed an iOS app (https://ayahbyayah.com) using Objective-C in 2012 (10 years on the AppStore next month)
Re-developed in Xamarin.iOS in 2016 which has been a solid decision due to the productivity gains I get from C# and Visual Studio tooling.
Xamarin.Forms works well for line of business apps and the performance with iOS was fine, however encountered a number of Android performance issues which is simply due to the nature of the framework.
Re-developed in Xamarin.iOS in 2016 which has been a solid decision due to the productivity gains I get from C# and Visual Studio tooling.
Xamarin.Forms works well for line of business apps and the performance with iOS was fine, however encountered a number of Android performance issues which is simply due to the nature of the framework.
Making a choice based on popularity of the tool might be the wrong approach. If making a choice is even needed.
If I would start something now I would most definitely go for Swift/SwiftUI and Kotlin/Jetpack Compose. I find that productivity, developer experience are best with those as soon as one gets the hand of them.
Also, these are the only ones to be guaranteed to be around long-term. While any of the cross platform options sound interesting, there is no guarantee they will be around.
If I would start something now I would most definitely go for Swift/SwiftUI and Kotlin/Jetpack Compose. I find that productivity, developer experience are best with those as soon as one gets the hand of them.
Also, these are the only ones to be guaranteed to be around long-term. While any of the cross platform options sound interesting, there is no guarantee they will be around.
Xamarin (native) used to be my go-to technology for cross-platform mobile apps, but Microsoft has absolutely driven it into the ground since the acquisition. Looks like they only care about MAUI, for which I couldn't care less given the horrible user and dev experience.
The motto for Xamarin used to be "you can do all the same stuff you can do natively, with day one support". Not anymore, and it's disheartening to see.
The motto for Xamarin used to be "you can do all the same stuff you can do natively, with day one support". Not anymore, and it's disheartening to see.
As a C# developer currently trying to improve my skills in UI development this HN thread is enlightening (thank you) but really demoralizing...
I noted down the following technologies to be the next thing to learn / take a look at:
An AvaloniaUI example App named Camelot[2] looked good at first, but after testing this on different OSes made me think, that performance wise there is a lot of room for improvement.
So far i have given flutter a wide berth because learning a new language (Dart) AND a new framework did not seem to fit my time capacities, but what I've read here makes me think, that even writing a simple cross platform app it is not worth the effort learning another C# UI technology, because they mostly get abandoned before they really mature.
My personal conclusion: Use Flutter instead! Am I right?
[1]: https://dev.to/avalonia/turning-it-up-to-11-34jn [2]: https://github.com/IngvarX/Camelot
I noted down the following technologies to be the next thing to learn / take a look at:
* MAUI + Blazor Hybrid (no official linux support, which usually is a no go for me)
* AvaloniaUI (looked very promising, especially the 11 Preview1[1], although not microsoft)
* Uno Platform (also not bad but not from Microsoft...)
An AvaloniaUI example App named Camelot[2] looked good at first, but after testing this on different OSes made me think, that performance wise there is a lot of room for improvement.
So far i have given flutter a wide berth because learning a new language (Dart) AND a new framework did not seem to fit my time capacities, but what I've read here makes me think, that even writing a simple cross platform app it is not worth the effort learning another C# UI technology, because they mostly get abandoned before they really mature.
My personal conclusion: Use Flutter instead! Am I right?
[1]: https://dev.to/avalonia/turning-it-up-to-11-34jn [2]: https://github.com/IngvarX/Camelot
Dart feels like a lite version of C#, so it shouldn't take you too long to learn.
Performance wise Flutter too has room for improvement. Although, I don't know how Flutter's performance compares to Avalonia.
Flutter, being young framework itself, is probably more mature than Avalonia, Uno or MAUI. Also, Flutter has very good documentation and learning materials and bigger community.
When I'm working with Flutter I do miss more powerful C#, but I for sure don't miss XAML.
Performance wise Flutter too has room for improvement. Although, I don't know how Flutter's performance compares to Avalonia.
Flutter, being young framework itself, is probably more mature than Avalonia, Uno or MAUI. Also, Flutter has very good documentation and learning materials and bigger community.
When I'm working with Flutter I do miss more powerful C#, but I for sure don't miss XAML.
Thanks for the impressions. I think I will try it out :-)
For .NET cross-platform UI there are:
MS frameworks:
- MAUI (ex Xamarin.Forms) which is similar to React Native as it's controls use native widgets for rendering.
- MAUI Blazor which is similar to Electron and Tauri as it uses web view to render widgets.
- MAUI.Graphics.Controls (experimental) which is similar to Flutter as it uses Skia to render it's controls.
Non-MS frameworks:
- Avalonia
- Uno
Both Avalonia and Uno are similar to Flutter as they use Direct2D, Skia, etc for rendering. Quick comparision I just found: https://github.com/robloo/PublicDocs/blob/master/XAMLFramewo... Note, that it's already a bit outdated as Avalonia 11 is adding support for mobile and WebAssembly.
Avalonia was more focused on desktop (Windows, Linux, macOS) until recently. Android, iOS, WebAssembly is still in preview. However it does support embedded platforms, like Raspberry Pi, Torizen. It's also able to run without a desktop environment. https://dev.to/avalonia/turning-it-up-to-11-34jn
Uno I think was more focused on mobile in the beginning and expanded from there to other platforms.
All of these frameworks are build around XAML. There is some support for using C# instead of XAML, but most docs/examples are for XAML. Search 'C# Markup' for more more details.
MS frameworks:
- MAUI (ex Xamarin.Forms) which is similar to React Native as it's controls use native widgets for rendering.
- MAUI Blazor which is similar to Electron and Tauri as it uses web view to render widgets.
- MAUI.Graphics.Controls (experimental) which is similar to Flutter as it uses Skia to render it's controls.
Non-MS frameworks:
- Avalonia
- Uno
Both Avalonia and Uno are similar to Flutter as they use Direct2D, Skia, etc for rendering. Quick comparision I just found: https://github.com/robloo/PublicDocs/blob/master/XAMLFramewo... Note, that it's already a bit outdated as Avalonia 11 is adding support for mobile and WebAssembly.
Avalonia was more focused on desktop (Windows, Linux, macOS) until recently. Android, iOS, WebAssembly is still in preview. However it does support embedded platforms, like Raspberry Pi, Torizen. It's also able to run without a desktop environment. https://dev.to/avalonia/turning-it-up-to-11-34jn
Uno I think was more focused on mobile in the beginning and expanded from there to other platforms.
All of these frameworks are build around XAML. There is some support for using C# instead of XAML, but most docs/examples are for XAML. Search 'C# Markup' for more more details.
MAUI is less cross-platform friendly than you might think. I'm using Avalonia right now, which works well.
How so? Buggy features on certain platforms or something else?
It doesn't run on Linux. Not sure how they can call it "cross platform" if it doesn't run on Linux. Maybe across Microsoft's platform.
Across Microsoft's platform? It runs on iOS, macOS and Android.
Linux desktop is a insignificant dwarf compared to the forementioned. It's also super fragmented (what is linux desktop anyways?) and hence a ton of work to have something reliable working there. It's easy to understand why it has not been included as a first-class citizen for MAUI.
dotnet core is also open source and runs perfectly on linux, but again -- desktop no bueno.
Linux desktop is a insignificant dwarf compared to the forementioned. It's also super fragmented (what is linux desktop anyways?) and hence a ton of work to have something reliable working there. It's easy to understand why it has not been included as a first-class citizen for MAUI.
dotnet core is also open source and runs perfectly on linux, but again -- desktop no bueno.
How do MAUI windows apps run through Wine? Not exactly cross platform but could be an option.
It's for front-end development. There are ~0% use cases for a linux UI outside of development tools and maybe database monitoring tools?
I daily drive Linux and I kind of agree with you. The amount of people I know that use Linux, use non-dev apps on their laptop/desktop, and aren't developers are zero (excluding myself obviously). The actual percentage of non-dev native gui tool users on Linux is probably within the noise of the measurable data.
There are plenty of people who daily drive linux that would disagree with there being "zero use cases"
If you ever are curious about how product managers make their decisions, it's based on more that 'plenty of people'. If you want to be a good engineer, you should also learn the difference between zero and approximately zero, if you want to quote people.
I used to write xamarin apps for a living.
It was great, until it became terrible.
Nowadays I don't develop mobile apps anymore. Last time I checked, Xamarin Forms was half decent to build simple apps, but you have to be pretty flexible on the specs and the visual design.
Still, for data entry apps and other simple purposes, it can be fine.
It was great, until it became terrible.
Nowadays I don't develop mobile apps anymore. Last time I checked, Xamarin Forms was half decent to build simple apps, but you have to be pretty flexible on the specs and the visual design.
Still, for data entry apps and other simple purposes, it can be fine.
You may want to take a look at Nevron Open Vision (https://www.nevron.com/products-open-vision.aspx). This is probably the most advanced desktop cross-platform application development framework around. I work for the company that created it and we have internally compared it to MAUI, Uno, Electron Qt etc. Nevron Open Vision is better in all aspects - it supports more controls, better integration and now also supports Blazor-WebAssembly! MyDraw is one commercial application built with it and tested by thousands of Windows and Mac users.
Xamarin is apparently merged into .net 6as .Net.maui. i only know 1 application that is multiplatform and relative popular: keepass.
As a .NET developer that's focused mostly on web development (e.g. APIs + SPAs), I've not been very eager to wade into the pool of XAML that is .NET desktop/mobile frameworks.
But I'm becoming more optimistic with the introduction of Blazor Hybrid. Whether you're using MAUI for mobile & desktop, or WPF/WinForms for just desktop, Blazor Hybrid provides you a web view that enables usage of Razor components made of C#, HTML & CSS. These components run natively, not in the browser.
After using Maui + Blazor with Tailwind for styling in a recent side project, I can see this becoming a viable alternative to Electron.
But I'm becoming more optimistic with the introduction of Blazor Hybrid. Whether you're using MAUI for mobile & desktop, or WPF/WinForms for just desktop, Blazor Hybrid provides you a web view that enables usage of Razor components made of C#, HTML & CSS. These components run natively, not in the browser.
After using Maui + Blazor with Tailwind for styling in a recent side project, I can see this becoming a viable alternative to Electron.
How is the performance? I was tempted to do some blazor work after trying some blazor demos on my M1 Mac. Then I tried it on my not-that-old Xeon windows desktop and it was unusably slow. It can run Google Earth and Visual Studio (and a whole bunch of electron apps) just fine, so my assumption was that Blazor is actually just bad.
When you say performance, are we talking about the tooling, running the app itself, or both? Also were you using Blazor Server, WASM or Hybrid?
Personally I've not run into any big issues like that; although my work laptop is pretty beefy, I did my side project on an old laptop that can't handle really large .NET solutions (e.g. crashes every 10-30 seconds simply navigating the Roslyn codebase...), but it did okay with Maui + Blazor Hybrid.
Alternatively, I think it's possible to use vscode if you're friendly with the dotnet cli, but I had trouble getting the workloads to work correctly and didn't wanna fuss with it at the time.
Personally I've not run into any big issues like that; although my work laptop is pretty beefy, I did my side project on an old laptop that can't handle really large .NET solutions (e.g. crashes every 10-30 seconds simply navigating the Roslyn codebase...), but it did okay with Maui + Blazor Hybrid.
Alternatively, I think it's possible to use vscode if you're friendly with the dotnet cli, but I had trouble getting the workloads to work correctly and didn't wanna fuss with it at the time.
I'm maintaining a cross-platform headless application at the moment. The frontend is in Java maintained by a different team. Dotnet core works pretty well for Windows/OSX/Linux.
The UI story is .. less encouraging. I'm not sure a UI that's both cross-platform and native-compatible is even possible. Microsoft have a load of offerings none of which anyone is really happy with.
I think the main way of building a cross-platform app in C# is not Xamarin but Unity...
The UI story is .. less encouraging. I'm not sure a UI that's both cross-platform and native-compatible is even possible. Microsoft have a load of offerings none of which anyone is really happy with.
I think the main way of building a cross-platform app in C# is not Xamarin but Unity...
I had a play with it and Avalonia on Mac, Windows and Linux: https://taoofmac.com/space/blog/2021/11/14/1600
However, right now I’m actually writing a simple GUI app in Godot (the game engine), because it is the closest thing to Delphi/Lazarus that I can actually be productive in…
However, right now I’m actually writing a simple GUI app in Godot (the game engine), because it is the closest thing to Delphi/Lazarus that I can actually be productive in…
As mentioned Xamarin is now MAUI[0]
The only app I know of using it is Bitwarden[1]
[0] https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
[1] https://github.com/bitwarden/mobile
The only app I know of using it is Bitwarden[1]
[0] https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
[1] https://github.com/bitwarden/mobile
I've deployed an MAUI-app to production. I chose MAUI since the rest of the stack is dotnet and we have ready built SDKs in dotnet to communicate with the backend, so I had a functioning login page up and running in minutes.
It was a very frustrating experience in the early days, but as MAUI has matured it's now a pleasure to work with. It is not as feature rich as some other frameworks, but it fulfilled our needs.
It was a very frustrating experience in the early days, but as MAUI has matured it's now a pleasure to work with. It is not as feature rich as some other frameworks, but it fulfilled our needs.
naikrovek(1)
There are gui frameworks made by the community as well. Avalonia has picked up steam since it supports Linux and has been around for a while. Documentation is lacking and I can never get it to work the way I want but I suspect that's more my fault than theirs.
Uno is another cross platform C# gui framework. I gave up on C# gui apps before I ever tried it out, but it looks good.
Uno is another cross platform C# gui framework. I gave up on C# gui apps before I ever tried it out, but it looks good.
You could try google's flutter: https://flutter.dev/ for cross platform. I'm currently building a sample app and seems to target and work decently well across the biggest platforms - web, mac, win, linux, ios, android.
IMO, You should only build on .NET platform if there are usable components which are already made in .NET.
Keeping up Cross-platform framework updated with the changing OS versions is difficult.
Preference would be to use Flutter (Google) or React Native instead of Xamarin.
Keeping up Cross-platform framework updated with the changing OS versions is difficult.
Preference would be to use Flutter (Google) or React Native instead of Xamarin.
Xamarin is now called MAUI. You'll find better search results using the MAUI term.
I don't trust the "new nice microsoft this time it's true we love FOSS and users I swear" enough to tie my stack to any of their products.
Things like VSCode, github or azur pipelines are ok because the cost of a potential migration away from them is tiny compared to the benefits they bring.
However, basing your entire code base (e.g: with .Net), dev env (e.g: codespaces) or infra (e.g: azur cloud) on their tech is betting that a company with a terrible track record will never, ever, go back to its previous bad practices.
I'm not making that bet.
Things like VSCode, github or azur pipelines are ok because the cost of a potential migration away from them is tiny compared to the benefits they bring.
However, basing your entire code base (e.g: with .Net), dev env (e.g: codespaces) or infra (e.g: azur cloud) on their tech is betting that a company with a terrible track record will never, ever, go back to its previous bad practices.
I'm not making that bet.
I use Godot for cross-platfotm native apps, specifically the Mono version. Very excited for the .NET 6 version to become generally available soon.
Things have worked just fine for me, though I haven't made anything too serious with it yet.
Things have worked just fine for me, though I haven't made anything too serious with it yet.
Without third-party libraries and/or frameworks, you can't target the same desktop applications that Electron can. For instance, .NET didn't have a cross-platform desktop offering until the last few months with the introduction of MAUI, which supports both Windows and MacOS, but not Linux.
However, if you go outside of what Microsoft offers directly, there's many options, some of which do something similar to Electron. Two off the top of list is the Uno Platform and Photino. There's others. They come and go.
However, if you go outside of what Microsoft offers directly, there's many options, some of which do something similar to Electron. Two off the top of list is the Uno Platform and Photino. There's others. They come and go.
NET and can be used to develop applications which run on Android and iOS.
Not available for FreeBSD? Not very portable across platforms, it seems.
For example, Electron is often discussed on HN (liked and disliked), but .NET is far less discussed as a cross-platform option.
Similarly, Xamarin is a platform built on top of .NET for building Android and iOS apps (using one codebase). This sounds like the holy grail of mobile development. But what is the reality?
I did a search on HN and found no stories about Xamarin from the last year. The top search results are HN stories from 5-10 years ago. This makes me wonder how popular .NET is for cross-platform desktop or mobile apps.
What has been your experience using .NET writing cross-platform desktop and mobile apps?