Uno: Create Beautiful Cross Platform .NET Apps Faster
platform.uno
platform.uno
- What is the license? Apparently Apache 2.0 [1].
- What is the minimum web bundle size and startup time?
- On desktop, what is the minimum RAM usage? Binary size?
- Is there a WYSIWYG editor?
[1] https://github.com/unoplatform/uno/blob/master/License.md
https://github.com/unoplatform/uno.toolkit.ui/blob/main/LICE...
https://platform.uno/uno-toolkit/
DEV FRIENDLY LICENSING
Uno Toolkit License
Uno Toolkit is available for free for individual developers and businesses with revenue of less than USD 1,000,000. If your revenue exceeds this threshold, please reach out to us to obtain a license for Uno Toolkit and access the complete suite of development accelerators.
We're also building products of Uno with licensing, first one being the Figma plugin for Design-To-Code: https://platform.uno/unofigma/
Uno seem to be starting to go down the enterprise support route - plus open core with their recent Figma plugin release. At least the Figma plugin is very tangential to the core product so it's hard to imagine it competing for features at this stage.
Though with the recent spate of open source company rug-pulls, and I'd struggle to justify using it. It seems like open source is increasingly just being used to build market share, then the VC/PEs come in, make a "contact us" enterprise pricing page, and suddenly issues and PRs start getting rejected because they compete with the paid add-ons.
I really hope the same won't happen with Uno, because it looks like a great library, and something that's missing from the dotnet world. Their sustainability blog post gives me hope, but... sadly it would not be the first time that founders with good intentions find out that running an open source company is nearly impossible, end up taking funding to keep up, then the rest is history.
Uno as a UI framework is and will remain FOSS. It's been our strategy from day one and core to how we operate.
We see real opportunities to build productivity-focused products on top of it that will bring licensing revenues. Our Figma Design-Code plugin is a proof point and we have a lot more to come.
Thank you for caring and for the insights.
It's fair for us to be gunshy. There's simply too many examples of OSS projects highly used across the web that made these kind of promises earlier on in the product's lifecycle, many if not most of them with the best of intentions at the time the promise was made. I trust that what you're saying is true today. Until we start to see more OSS projects with sustainability models that are both successful at staving off negative influence from funding partners, and those sustainability models leading to companies making good on the declarations of altruism they made when they were younger, I think we're going to remain unsure and unconfident in promises like this.
Don't think it's going to stop us from checking out your product or potentially building really cool stuff with it. But until you prove to us that you'll keep this ethos, we will start using this really cool framework with one hand while we keep another hand free to stabilize ourselves in what feels like an inevitable rugpull that isn't a matter of if, but when.
I'm sorry I wrote this as I didn't actually review the project and see if the source code is available. It appears to be closed source. Your concerns are definitely valid.
My comment was more directed to open source, and I would say to you that the only in-perpetuity guarantee is to fork it.
We're actively working on bringing an unified OpenGL control in our Toolkit so it works on all platforms and be ready-to-use. Stay tuned!
I think the main benefit with this approach is expected-behaviour (like how different desktop operating systems have different textbox behaviour), and that whatever accessibility you get by default with native controls is there. [1]
I don't really find their approach to GUI development compelling though, with them choosing a middle ground between "wrapper around native controls" and "implement everything yourself".
[0] Except on Linux and web, where Uno draws everything itself, imitating controls that look like GTK (on Linux) or UWP/WinUI (on web). These are the platforms I briefly tested on and I didn't have an enjoyable experience with the output due to non-native/non-expected behaviours.
[1] Page on accessibility: https://platform.uno/docs/articles/features/working-with-acc...
On Linux, we've just released our support for X11, removing the need for GTK. As we're drawing the whole app surface, we're always interested in adjust the UX of our controls on individual platforms. If you have examples, let us know.
Finally, for WebAssembly, our current rendering backend is using the HTML DOM, which means that accessibility and other native behaviors are functional. Same here, if anything accessibility related is missing, we're all ears!
I didn't know that the HTML DOM is being used for Uno's web output but that's good to hear. I was under the impression that things were being drawn to canvas (like how Flutter's web output works) but functionality like Ctrl-F (text search) works on https://gallery.platform.uno/, showing that's not the case.
I'm not sure why I had the impression that the web output used HTML canvas, but maybe that was something that changed since I last looked a few years ago or there might be another reason I was mistaken.
I think one misleading thing that gives the wrong impression is that text isn't selectable on Uno's web output (like https://gallery.platform.uno/), similar to how text isn't selectable on HTML canvas.
I think it's worth having a discussion about that with other employees, because it's one divergence from user expectations about how the web usually works (but application developers may also prefer to make text not selectable so it may be the behaviour you want in some cases after all).
Therefore you can embed native controls.
It used to have a dependency on GTK but no more since the 5.2 release.
There's just no notion of "native controls" that you can embed in an Uno Linux app like you could have if you wanted to embed a 3rd party native UIKit control on iOS.
2: https://calculator.platform.uno
UWP left behind a shockingly large number of perfectly serviceable pieces of WPF, at a time when the emergent UI experience on Windows 8 was being written off by almost everyone, Windows Phone was DoA, and people were starting to realize they could just write web pages and run GUIs in the browser instead. It's been a long, bumpy, downhill ride ever since. The fact that Electron.NET and Blazor is a serious UI suggestion from Microsoft these days should tell you everything you need to know.
I'm sure with enough effort it's usable and maybe even nice in some ways. I did some proof-of-concept work with it two years ago and got maybe 50% of the way to where I wanted to be in 8 hours, but got stuck at styling issues for which there was limited documentation. In the end, I'm more confident these days in WPF + Avalonia if I really need cross-platform - even if there's comparable bugs and limited documentation, there's at least some momentum still behind the project. UWP, all three busted half-finished versions of WinUI, MAUI, Blazor + Webview2, Blazor + Electron.NET... even Avalonia, thanks to the weird decision to change styles to behave more like CSS... it all still struggles to be as usable as WPF.
The whole industry is unfortunately moving towards web interfaces being the default. That is unfortunate but it is an industry wide trend.
You can use tkinter, which doesn't work well with native platform features and forces you to rewrite your app from scratch in something else when you finally need to do accessibility. QT is free for noncommercial use only. WX kinda sorta works, but WX apps on Mac feel like they were on Windows, and the naming conventions are extremely unpythonic. Toga looks like a nice option, but it's still pretty young, I'm not sure how far I'd trust it.
How so? It’s LGPL.
WPF, a framework from 2006, and Avalonia, a 3rd party framework, are the only two worth considering.
I wish Avalonia UI's mobile solution had had Navigation sorted a year ago when I proposed that we needed to do something with the XF EOL announcement. I had a POC with it working well enough, but sadly it was "too much work" to migrate the rest of the app. Now with MAUI we have realised that we are probably doing just as much work anyway, and it is seriously half baked as an ecosystem.
As well with the rise of new tech/stacks that has displaced C# in a few places, the people who stay in C# tend to bristle at other OSes as that's what the people who are using the other techs use (and us vs. them type attitude).
So in the grand scheme of things, it's unsurprising that this happens.
Our production environment where all applications are run is based on Debian (though we test on Windows Server as well) in a kubernetes cluster, running in Azure.
C# is decent language for writing line of business application logic, and these days .Net is a completely cross platform, open source framework.
I remember using a bunch of C#/Mono applications (F Spot, Banshee, etc, they were all the rage once) on my Linux desktop over 20 years ago.
Keep in mind that .NET has "inherited" a huge ecosystem and developer community that existed and still exists within the confines of .NET Framework. It roughly splits into two groups - the one that is moving or has moved on to .NET and left the legacy in the past and the one that harms the ecosystem by refusing to do so. Luckily, the former is in the minority compared to the latter especially as the time goes by.
It is also helped by new generations of developers who came into working with the tech after .NET Core and .NET became the mainstay or developers who moved on to .NET from other languages and ecosystems.
Fastforward to .NET 5, 6, 7, 8.. it's just doing great x-plat life and innovation
I'm one amongst many using Net on other systems (Mac & Linux) as well as Windows. Larger enterprises which use VS on Windows often deploy the results onto Linux servers too (especially with microservices), which is hardly being hostile.
Though to address the issue of GUIs in Net-land, I've given up as nothing since WinForms (and possibly WPF) has lasted. They are 'supported' in many cases, but it always feels half-hearted or half-dead.
MAUI is pretty decent.
My hope is that MAUI gets to WPF level soon. Refactoring away from WPF to MAUI should be almost trivial, if desired.
Yes. Many FOSS ecosystems don't even have adequate GUIs, but they never had them. Microsoft had them but then lost them. Every "modern" replacement requires you to import a whole browser in some form or another with all the baggage that comes with it, both in terms of development, runtime and security.
I develop WinForms applications at work and we use .NET Framework by choice, to aim for long-term stability and not the 'new thing'. We are not stuck we're loose. It's important to understand that MS Windows will never be able to get rid of the ability to run .NET Framework apps. Also, even though the new .NET supports WinForms, it's not a 1 : 1 port yet and we've done extensive testing on this. Not using .NET Framework would mean degrading the performance of the app (~30%). Try it out for yourself with a controls heavy application. I'm talking 100+ controls on a single app with real-time data fed through it. We use 3rd-party WinForms controls that's been in development for over 15 years. The GUI is modern and the performance excellent.
Words like 'legacy', in our case, means better stability and higher performance, and frankly, we neither trust nor care about Microsoft's opinion.
That said, I can understand that the new .NET is useful and an upgrade for those who wants cross-platform support among other things.
For example, recently a customer wanted a security solution, a filesystem journaling application, powered by a low-level FS kernel driver (C/C++) together with a managed .NET assembly to interop with our unmanaged driver DLL. Running on the highest altitude - on top of the driver stack - means handling, filtering, and intercepting a huge amount of filesystem requests before it reaches other system components. Therefore, performance is key.
In that scenario, using modern .NET we experienced nonstop deadlocks which froze the whole system. .NET Framework had no issues keeping up.
I can also think of other examples e.g. issues working with custom virtual filesystems.
So yes, NET Framework would be my first choice for standard Windows-only desktop applications.
We were told to benchmark the performance on several computers using different hardware. In example 1 we calculated ~30% worse performance (worst case scenario!). In example 2 we had micro stuttering and system wide freeze (requiring reboot).
Again, in example 2, are we supposed to accept our customer computer freezing under load? In a high security, sensitive environment? You must be joking! Instead we delivered a solid product which do not freeze the system and we got great feedback. What's considered 'obsolete' is irrelevant to us. The word means nothing. Our benchmarks are of the highest importance.
Let me try again on monday though, I can reproduce the results then. Your claim piqued my curiosity, but I think you underestimate the specific requirements in which we work. Perhaps they've fixed something since last time we tried. I'm certainly willing to try again.
Like using the apis that fully utilize spans. Also, I have the feeling (but nothing tangible) that old .net and .net core do behave differently wrt async stuff too.
I'm actually curious myself after this discussion. I didn't port it, my coworker did it and I'd have to ask him. I did take part in the benchmark though and watched all the deadlocks happening.
Found this old screenshot of our internal FS driver debugging tool - to give you an idea of what I mean by needing high performance: https://postimg.cc/mc6YQFbC
24,654 filesystem events in C:\Windows\ in just 1 minute and 30 seconds on idle. 814 read operations (36,7MB) + 948 write operations (66,9MB). Now imagine this system-wide (not just the Windows dir) under heavier load. This is where modern .NET could not keep up leading to the aforementioned deadlocks.
Sorry that I can't provide more specific info at this time. I can find out more on Monday.
There can be latency differences in edge cases of interaction between threadpool used by specific version and Overlapped IO on Windows, but that's likely about all there can be.
It's important to note that .NET Core 3.1 -> .NET 5 -> 6 -> 7 -> 8 is a huge difference in compiler and corelib internals (less so in GC, with major steps in 6, 7 and 8 in regards to regions and now DATAS), so an issue that could have existed in one of the previous versions is likely to be fixed by now.
Instead, I've been told a half-dozen times that there's a new cross-platfotm GUI option, and had I bought into any such endeavor, I would have been rugpulled by sudden deprecation or loss of focus. I think people who did buy into any cross-platfotm GUI frameworks from Microsoft in the last ten years are justifiably feeling like they've been hung out to dry, sometimes multiple times.
I don't complain about Elixir, Ruby, Go, or Rust GUI development because I don't try to use these languages for GUI development, because their core leadership and marketing doesn't promote this as one of the primary use cases. C#, and the .NET ecosystem at large, are THE premier Windows GUI development tools. When their marketing pivots to cross-platform GUI development, and they rugpull you a half-dozen times in a decade with half-finished and baffling experiments, it kinda smarts.
Most people developing desktop apps are probably okay with switching to web-based options, including potentially running their own standalone rendering executable on top of a web view or chromium instance. But there's a significant minority that are building desktop apps because they want better performance and native visual integration/theming, who don't benefit from browser process isolation and the hairy JS event loop situation, who don't want to serialize every user action in the GUI, who saw what XAML set out to accomplish (GUI style templates that convert to framework code that could equally be hand-written, modified, or extended) and ran marathons with it. Maybe this will get better with WASM improvements in the next few years, but it doesn't change that the approach to GUI design is fundamentally different, and in a lot of ways needlessly harder, when you have to pretend your GUI isn't all running on the same machine.
Because no one in their right mind would write anything GUI related in those languages.
It doesn't get much love on HN but it's there, it works, I've used it to ship real apps.
• Delta software updates without code changes. On Windows apps update in the background even when not running.
• It can do web-style synchronous updates on app launch.
• Can build for every platform from any platform. Linux cloud CI workers can be 10x cheaper than Mac workers, so this feature can save you a lot of money!
• Lots of usability work and features around code signing/notarization. It can do signing without MS/Apple tools and it knows how to use cloud signing services, remote HSMs, local HSMs, the Mac keychain (protected from other apps), custom enterprise signing services that can only be accessed via scripts, it can check for many kinds of mistakes (a particular weakness of vendor tools), it will help you buy certificates by generating CSRs for you.
• Generates a download HTML page that detects your user's OS and CPU to give them a big green download button, it can upload all the artifacts to S3 or GitHub Pages/Releases or any other server via SFTP. It renders icons for you, etc.
• Deployment by Windows IT is easy and installation doesn't require users to have admin rights on their system.
• It can publish to the MS Store which lets you avoid needing to buy signing certificates for a one off $19 fee.
• It comes with commercial support. With other tools if you get stuck you're on your own.
----
All the above works for Electron and native apps too. For JVM users specifically:
• It figures out which JDK modules you need using jdeps and bundles a minimized JDK.
• It provides a Gradle plugin that can read config out from your build configuration automatically.
• Easily bundle JCEF if you want an embedded Chromium.
• (soon) It will provide an API that lets you check for updates and trigger them manually. This is done, it just needs to be fully documented and published to Maven Central.
• It has way better support for native code than jpackage. It will dig through your JARs to find native libraries that don't match the target machine and delete them, it will sign them in-place, it can extract them ahead of time and then set up your system properties to make them be loaded from the right places and so on.
• It can bundle custom TLS root certificates into your JVM trust store. That's especially useful for enterprise settings.
That's not even a complete list by any means. Conveyor is packaged with itself and is a JVM app written mostly in Kotlin, so the above features get dogfooded by us.
I wrote this tool partly because I really wanted to close the gap between web and desktop dev, to let developers have more freedom around frameworks and languages than they do today. It's not right for everyone but if you aren't hog-tied to the browser then the pain of distribution is really removed by this thing, and that lets you focus on building your app.
https://gluonhq.com/products/mobile/
Although it's not a mapping over the native UI toolkits so it has the same issues as Flutter etc.
Electron is just using HTML/CSS/Javascript that are open, Electron alone is MIT licensed and there are no tricks like "2 developers - well you have to buy $900 a year license".
I don't expect everything to be free as in beer but JavaFX looks shady. I would never build my business on their platform, would rather go with QT.
What's wrong with Qt? There's also Lazarus (https://www.lazarus-ide.org/) with almost transparent interoperability with C.
They may not be perfect, but in light of their existence, it's hard to argue that there is no real open and cross-platform GUI.
If you relax your definition of "open" a little bit, there's still things like flutter.
- I don't mind GPL or LGPL and I don't believe everything should be free as in beer -
Still QT company pushy marketing is making it hard to just build stuff on their free offering is a huge turn down, to do a build I need to login to an account, crazy (well the same for Apple, but not the case for javascript/html/css).
Last but not least Lazarus/QT - how long will it take and how much will it cost to build a team of 5 developers to build and maintain product on these. When I put an ad for JS dev I am pretty much flooded, for QT/Lazarus I never posted an ad, but my gut feeling is I will be lucky to get any CV in 3 months.
Things like staffing for specific skills is a different issue.
The comment I responded to did not say "There are simply no other Js+Html+Css browser-based alternative to electron".
If they did I would not have responded, because then they would be correct: there are few browser-based alternatives to Electron.
They said that there are no open alternatives, which is what I did respond to.
Because, to be honest, if you're in a company and a team, you are all probably going to use the most popular tech (whether electron or something else depending on the platform).
For all other types of developers, stack popularity may not be a factor at all. From the question asked, there was no context around the type of development or team.
For example, I'm an independent developer, writing custom software. It's faster for me to deliver a cross-platform desktop GUI in Lazarus than in Electron (the delivery speed of the GUI is not even in the same order of magnitude for the type of projects a solo developer can do).
OTOH, if the client needs the type of fancy CSS animation, theming, etc that only a browser can do, then you have no choice but to use the browser.
These days I feel like React Native is your best bet for open cross-platform GUI. Its a nifty idea: your app still runs in JavaScript but the rendering layer is replaced with something platform specific. There are some big warts (performance is NOT uniform) but its probably the best way for someone with frontend chops to leverage their skills for other platforms at this point. (Although for desktop Electron might actually be just as good or better, too.)
FX is not flushed out. Though it does have some data binding, which is all manual in Swing.
- Swing with FlatLaf look and feel, just exactly like the JetBrains IDEs, there’s a kitchen sink app JAR you can download from FlatLaf, there’s some nice extensions for the layout too, not for mobile though as far as I’m aware
- Vaadin and their 2nd framework whose name I forget, directly integrated with Spring and Quarkus
- Kotlin Multiplatform and Jetpack Compose Multiplatform, a very promising and awesome tech, works fine for my requirements, would be happy for them taking the lead, I love the syntax and their compositional semantics, similar to SwiftUI
- React Native worked great for me, can reuse some React.js stuff
- NativeScript, never tried
- Ionic Capacitor, never tried
I think it might make sense to watch a couple YouTube live coding showcase sessions with the respective developers.
Avalonia also has a kitchen sink app btw. And I really like Uno’s calculator app, though I recall having had a weird bug once in the calculation logic.
And as for Blazor, there’s always been JSF which have long had great UI components. To me Blazor is about replicating JSF.
Yeah, well, I wish there were just 1-2 really good choices to be made, but there’s a myriad of caveats in each framework, more so in some of them. Well, Qt comes closest I think.
They really messed up WinRT.
Although not perfect at Windows 8 launch, its evolution until Project Reunion came to be had potential.
It was .NET as it should have been from day one, a proper developer friendly wrapper on top of COM, and Microsoft had finally provided something comparable to C++ Builder for the C++ crowd.
Instead they never delivered feature parity to WPF, killed .NET Native, C++/CX, the designer, and then started from scratch on Win32 side, while expecting everyone jump to put up with them, and follow for the ride.
I consider that an ultimately lack of respect for paying customers.
I think this space needs some stability, and Microsoft seems keen on inducing volatility for some reason.
I really wanted to like UWP, then WinUI, but for anything that isn’t a simple demo project you end up spending all your time fighting the framework and facing broken/unpolished parts that make you feel pain and frustration.
Avalonia isn’t perfect and has some rough edges but I would still consider it for cross platform support over anything else.
Is there actionable feedback you could provide to it?
Key things that need to improve: - Documentation appears to have gotten better in the last few years, but still many sparse or underdocumented corners. This is my biggest reservation today. - When I last used it (a few years ago), a lot of things weren't fully implemented - maybe this has changed? But it added a lot of friction.
This is a 3rd party framework on top of .NET (which itself is a 3rd party on mobile) which is 2 layers of abstraction on top of the actual thing that will run on the user's device. Microsoft takes a full year to update their GitHub runners with the latest macOS and Xcode versions, can you imagine the risk of having to wait for so many parties to update/fix their things?
Flutter and RN are not immune to this effect, every year when there is a new iOS or Android release, existing apps just break and tooling takes quite some time to catchup. It's so many side quests suddenly appearing without added value for the developer or the user.
Edit: as someone else noted, the website itself links to a built-in option to do so as well - https://platform.uno/c-markup/
[0] https://github.com/AvaloniaUI/Avalonia.Markup.Declarative
[1] https://github.com/wieslawsoltes/NXUI
€19,500 For the 1st app. Second app only €4,500
But if you're making something from scratch, just use the free Avalonia.
By the way, Avalonia also supports NativeAOT, unlike WPF, if used with the compiled bindings feature. Pretty cool!
I worked at a shop that wouldn't hesitate to spend the 20k in a second if they had to.
[1] https://avaloniaui.net/Blog/migrating-wpf-applications-avalo...
Where did you go?
[Edit] Sorry, I see that you are talking about the "XPF". I didn't use that before.
I presumed that this was OpenOffice internals that support cross-platform UI and OpenOffice scripting.
But apparently, the 'Uno' internals in OpenOffice are just the internal object message bus and don't have anything that is visible to the user.
Maybe this opinion piece might help: https://www.codeproject.com/Articles/5366945/Multiplatform-X...
His conclusions:
«Now what I mean by "better" - it (ed: Avalonia) allows considerably faster development, maintenance and support of the products. In particular:
- It is a more powerful UI package allowing much more re-use and creating shorter code faster to achieve the same functionality. Part of the reason for that is that it is not confined to WinUI/UWP bounds - it is actually more powerful than WPF which is in turn better than WinUI or UWP. Another reason is that it has a better implementation with a lot of code re-usable across all of the platforms while Uno and MAUI essentially have completely different implementations for each of their platforms.
- There are many features in Avalonia that are not implemented in Uno or MAUI, while I do not know a single feature implemented for Uno or MAUI that would not work in Avalonia. If someone knows a single feature available in Uno or MAUI but not available in Avalonia, please mention it in the comments and I will refer to it in this article.
- Avalonia covers all the same platforms as Uno and more than MAUI does and has considerably fewer differences between behaviors on various platforms.
- Avalonia is easier to switch to for an expert WPF developer than to Uno or to MAUI.»You can leverage some of our existing design systems like Material/Fluent and customize them: https://platform.uno/docs/articles/external/uno.themes/doc/t...
Or you can start from scratch and define your own styles.
By default, they will be pixel-perfect and look the same on all platforms.
Has been in development since 2013.
Fun fact, I worked on NativeScript team, and now on Uno team.
Main differences are that it also targets Linux+WebAssembly, and it's meant to be Pixel-Perfect so it would look and behave the same on all platforms by default.
It also offers a variety of additional packages out of the box and aims to be an end-end platform instead of solely a UI framework: Hot Reload, C# Markup alternative, a toolkit of mobile-first controls, design systems, reactive state management (MVU-like), recipes for Authentication/Navigation/Logging/DI/...