39 comments

[ 2.2 ms ] story [ 128 ms ] thread
The author spends most of his time ranting about Xamarin Forms, but the article is also about the advantages of the Uno platform. I have only dabbled in app development until now, but being able to easily build cross-platform app(lication)s for iOS, Android, Windows, MacOS and Linux definitely sounds interesting. Unfortunately it's apparently tied to C#, which I'm not familiar with at all...
C# is pretty similar to Java, so the jump isnt too far if you know that.

C# also comes with Visual Studio, which can be used in the free version with teams of up to 5.

I myself barely used it either though, most of my development is in java, JS/TS and python.

As far as I know, it is superior to Java. or Java finally got async/await? - the feature that is available for ~10 years in many other languages including C#...
Flutter is probably the better bet for the future
"Flutter is Google's UI toolkit...."

No thanks. Why would you build with a tookit from a vendor that has such a history of abandonware?

I've been a Xamarin.Forms developer for a while and I'm a big fan of the framework.

The author has a point that Android support has always lagged iOS support, but I've not had problems to the point that they have. Xamarin is great for business apps, and can definitely be performant on both platforms.

The thing that I, personally, desperately care about is cross-platform on the desktop: Mac, Windows, and Linux.

MAUI was promising to become such a thing [although MS themselves are being a bit non-committal about Linux], but should I be wary of the bigger architectural picture?

WinUI 3 builds on the legacy of earlier XAML-based frameworks, and isn't entirely a brand new product (unless you're on non-C#, then the whole C++/WinRT API is brand new, and actually kinda nice (speaking from having used Gtk and Qt before)).

You shouldn't be wary realistically because Microsoft has spent almost a decade grinding away at something that needs to exist for both Windows to survive, and for Microsoft to stay relevant in app design. The existing code that makes WinForms, WPF, and WinUI 2 apps (the API in UWP) also has been reused or extended by WinUI 3.

Microsoft just wants app development not to suck. They designed C# for a post-Java world for this goal, they rebooted Visual Studio years ago for the C# era to achieve this goal, they took XML out of the places it didn't belong and put it into the places it did belong (ex: XAML, for actual real document-style code autogeneration) for this goal, they switched to Git to handle their famous monorepo to accelerate development of Windows, they bought Github because of how much they used it internally (and made their job so much easier than their kinda shitty internal mixed heritage VSS quasi-fork), and they're one of the largest users and committers of the Linux kernel itself and would love if they could run their own modern MDL2/Fluent(=MDL3) apps on Linux natively.

The particular complaint mentioned in the article is Java <=> Mono transitions in Xamarin.Forms and if your focus is on Desktop that's not a concern on any of the desktop platforms.

.NET has long been rock solid in C/C++ <=> .NET transitions and WinRT <=> .NET transitions. (System.Windows.Forms does a ton of it and .NET 5 seems to have the expected performance from all those transitions.) The new interesting transition that it is still too early days to tell how well it will perform is the new .NET approach to Objective-C <=> .NET transitions/projections (which is more like the modern WinRT projection techniques) that is also different from the Objective-C <=> Mono transitions in Xamarin.Forms. (Though the article points out that the Objective-C <=> Mono transitions were fine and the new .NET approach on paper should be even better.)

Also, from what I was reading, a modest version of the architecture change that the article was lamenting needed to happen to reduce Java <=> Mono transitions in Xamarin.Forms is supposedly happening in MAUI and they were trying to reduce the surface of "managed Renderer" code that transitioned in/out of OS level services. I don't know if what they are doing would be enough to satisfy the article's writer, but it apparently has been something on their radar.

Uno looks like a poor man's Flutter, they went ahead and redid controll rendering but they still use native controls for behaviour and apparently use native rendering paths for each platform. So you basically have to trust them to get it consistent between platforms across paths ? Not sure why you don't go all the way and handle everything like Flutter, at least the rendering is unified between platforms.

Having now used multiple of these cross platform frameworks (Xamarin Forms, Flutter, Ionic) frankly I'd just write the UI for each platform separately and use native design tools, using common C# library for business logic.

Otherwise use Ionic/WebView if you don't care about result quality and need fast development, you'll knock out a web UI faster than anything, every front-end dev can do web, plenty of design tools, designer workflows.

The entire point of Uno is being an implementation of UWP (notice the very specific goal here), while using native UWP with no overhead when on Windows.

Since WinUI 3 is multiplatform (in conjunction with the first party Linux/Android and OSX/iOS support in .Net 5 and 6, and with MAUI), Uno no longer needs to exist outside of dealing with legacy UWP code (which, as per Microsoft rules, shall never die).

Also, re: web UIs, I hate to inform you, but everyone hates these. They are slow, clunky, optimized for all the wrong things, inconsistent, and sometimes ugly. The move to HTML canvas-based UIs in otherwise native apps Android and iOS is why most apps on phones are slow, even though a purely native one would have been fast on an ancient phone. Please do not repeat this mistake.

If you are building form apps and stuff where delivering something working is the main objective (most enterprise apps) web UI is by far the best choice - ecosystem is huge, plenty of developers and designers to hire, tools let you export stuff like styles directly from designs, etc.

If you care about user experience - writing it for each platform would have ended up being faster in the last app I did with flutter - so many subtle things that dragged the development out for weeks where as native had all these things working out of the box. I haven't worked with Xamarin in a while but I remember the quality was the worst out of all solutions I've used. So many moving parts, "this works in the latest version" and then half of other dependencies haven't been updated, and you just said the same thing.

> Since WinUI 3 is multiplatform

Hm? I thought MAUI was the multiplatform UI toolkit and WinUI 3 was the native Windows 10 UI toolkit (evolved from UWP) repackaged for bundling with each app?

Multi-Platform in the windows division means Xbox, older win 10 versions and things. Microsoft uses this term very naive.

I hope I do not destroy the dreams of someone.

> I hope I do not destroy the dreams of someone.

You kinda did. :)

I was trying to grok the point of Uno if WinUI was truly multi-platform in the MacOS/Linux/Android/iOS sense.

Just like for Apple multiple platform means macOS, iOS and watchOS, because at the end of the day it isn't the same OS, nor hardware.
Yes, but Flutter uses a strange little JS dialect nobody wants to learn. Were both created due to the way Google gives out bonuses and promotions?
Dart is much more similar to C# than JavaScript
It's the worst of all worlds TBH. It has terrible reflection and metaprogramming capabilities which leads to ridiculous solutions like code generators at every step. Type system is super weak (eg. it just gives up on type checking ternariea for eg., had multiple runtime type errors because dart couldn't catch it at compile time), but at the same time also closed and very inflexible. Working with immutable types is ridiculously bad compared to C# or JS. Serialisation is terrible as well.

Flutter would have been a much better framework if it was built on typescript

I dont' think that really matters. If Flutter solves the cross platform issue, people will deal with Dart. And if Flutter sucks, nobody will put up with it sucking just because they love Dart. Either way Dart isn't the big picture, Flutter is.
I disagree. I would not recommend flutter to anybody precisely because of how bad Dart is. It's such a productivity/maintenance drag that the framework is not worth it.
The author claims they created a great Forms UWP app which is deeply suspect. Also, Uno don’t really address anything but the performance issues of Xamarin on Android in the list of things Forms is bad at, so beware.

Argument about UI is also suspect. Forms gives a lot of customization control, and with the new material visual you can get a good cross-platform material design. Personally, I think Material is ugly, but it isn’t exactly uncommon these days.

At this point I also hate Xamarin.Forms, but I like Uno even less, mainly because it is built off the absolute abomination that is UWP. (Heads up: it renders paths/SVGs even worse than WPF). If you are a .NET developer, you do not want to explore the mess of buggy controls, COM threading issues and old Silverlight help pages that is UWP. Yes, when you sign up for UWP, you are signing up for an immature wrapper over COM.

Best forum software projects now is NodeBB and Discourse.
I played around with Uno... a sample "Hello World" app took like 10 seconds to load, placed a godawful amount of cruft in my project folder, and dragged Visual Studio to a crawl, on my 4core/4ghz, 32gb RAM desktop

Whatever Uno is supposed to be, I was very disappointed

It still bothers me that they choose to call Xamarin Forms successor .Net Maui. There is already a project for building user interface called Maui (mauikit.org) and now because of that some Microsoft partners are starting to reuse the name (e.g. mauikit.com)
I liked the name Xamarin because it's unique. OTOH Maui is a well-known toponym, reused as a name of many other things.

I really dislike this name overloading. It hampers search. It adds no value. It leads to name clashes.

I much appreciate unique names without much pre-loaded meaning, like Google, or Kodak, or Inkscape, or Linux, or Debian.

Apparently coming up with such a name is hard, though, especially because of a desire to come up with an excellent pun / acronym, and because of the corporate desire to play safe and use a tried name.

One of the two big reasons a project I've been working on for years went with Xamarin Forms is _because_ of native appearance on each platform. If you want your app to look the same on every platform and not take advantage of each platform's individual strengths, then just stick with HTML+JS.
I agree, this is in my opinion a strong point of Xamarin Forms over the competition, the native experience.
I guess they wanted their app to look the same as other apps on that platform.
I agree. I actually take offense to the article implying that matching iOS/Android UI is due to… laziness? On my iPhone I deleted google maps purely because it somehow wants you to swipe up from the bottom of the screen to open the menu which, you guessed it, closes the app.
meh, nothing come close to SwiftUI, and if you need something crossplatform, stick to Flutter, declarative UI in 1 single language and code base is the future

XAML? no thanks

The issue with Blazor is that not just JavaScript is a legacy trash but that HTML and CSS are also legacy garbage.

It falls short of fixing the issue.

We need to make web open to technologies beyond the legacy stack.

I've been using Xamarin Forms a lot in the last 3 years or so and I like the framework. However, Visual Studio for Mac is a royal pain in the ass. I wonder if this is just my experience (maybe some weird config settings in my project or something) or if many people feel the same.

I use a 3.4 GHz Quad-Core i5 iMac with 24 GB of memory. Storage is a Fusion Drive. On this configuration Visual Studio often slows down to a crawl doing whatever it does.

I've recently switched to JetBrains Rider [0] and the experience is so much better. Rider never slows down for me. Occasionally the debugger disconnects, but just closing and re-opening the project fixes this issue most of the time. The key binds take a bit of getting used to.

To improve my experience in Visual Studio the few times that I am forced to use it, I'm moving my view code mostly to C# files (not making use of XAML anymore). Since the XAML editor is also very often slow to autocomplete and such in Visual Studio.

So with Rider, I now have a good experience. Sadly Rider is not free, but it's also not very expensive and my developer experience has improved in a big way. Rider also gives much better advise for refactoring, which is also a nice bonus.

---

[0]: https://www.jetbrains.com/rider/

Tbh I don't think it's a problem with Visual Studio on Mac.

I think Visual Studio just kinda sucks in general. It's bloated and clunky and its editor feels incredibly dated.

Btw, if any student is reading this you can use Jetbrains IDEs and a lot of other stuff for free if you apply for the Github student dev pack. So that’s something worth considering :)

https://education.github.com/pack

I am porting my Android/iOS/Windows app to the web. Like the author, it has taken me years to make it work on all OSs. I could say that I am satisfied with performance

But a few weeks ago, Google humiliated me by removing my app from the store with no prior warning(it is back now). This has led me to explore building the app in WASM. Today, I have finally verified that the app's core functionality runs faster on a browser than on native Android or iOS