Comment by siwatanejo | Hacker News Reader

Comment by siwatanejo | Hacker News Reader

In hindsight, I should have adopted used this in the past for the apps of my startup, instead of going for the Xamarin.Forms route.

Why do I say this? Because the migration from Xamarin.Forms to MAUI was (actually, _is_, as it's not really 100% finished yet) a horrible PITA.

Let alone the migration from .NETFramework to .NETCore (now called "dotnet" since v5) which delayed us months if not years (but people that used Avalonia would be affected by this too; so the way to dodge all this would have been choosing Flutter or ReactNative, I guess).

That being said, the main reason why I chose Xamarin.Forms over Avalonia at the time is because the latter didn't have Mobile support. How's Avalonia's mobile support now? Even if the port is 100% complete, I always thought "well, XF/Maui are centered around mobile, making desktop just be an after-thought", which to me is an advantage because I prefer better UX for mobile by default, and require devs to spend extra effort for desktop support (instead of the other way around); given that desktop usage of apps is declining day by day.

I've only ever seen mobile mentioned as "coming soon", but honestly, I don't think porting over the GUI library will make turning an application into a mobile one any easier. A mouse+keyboard design just doesn't fit a mobile screen well, you're going to need to redesign and reimplement large parts of your application regardless of what platform you pick. You'll probably get tablets working easily, but for mobile phones you'll need to put in the annoying grunt work.

I do like Avalonia for actually bringing a cross-platform .NET GUI to Linux and for that purpose it works quite well. I'm sure the toolkit will end up working fine for mobile just fine, as long as you design your application for the different form factors you may end up running on. Porting Xamarin Forms to Avalonia is going to be a hell of a lot easier than porting it to Flutter or React Native, but you'll still end up putting significant effort into the process if you want it to succeed.

Avalonia's big money-maker is their drop-in replacement platform for WPF, which allows you to basically take an old WPF application and turn it into a Windows/macOS/Linux/web application with two lines of code, if you're willing to pay the price. Perhaps they'll add some kind of auto-mobile-form-factor conversion to that system as well?

> Avalonia's big money-maker is their drop-in replacement platform for WPF, which allows you to basically take an old WPF application and turn it into a Windows/macOS/Linux/web application with two lines of code, if you're willing to pay the price. Perhaps they'll add some kind of auto-mobile-form-factor conversion to that system as well?

Ah interesting, I didn't know this.

> A mouse+keyboard design just doesn't fit a mobile screen well, you're going to need to redesign and reimplement large parts of your application regardless of what platform you pick.

I think you're understanding this backwards. I'm not aiming to port a desktop app to a mobile app, I'm aiming to choose a UI toolkit that works fine in mobile by default and requires tweaks in your app to make it work in desktop (rather than choosing a UI toolkit that works fine in desktop by default but requires tweaks in your app to make it work in mobile).

This is a pipe dream and will remain one.

Why? The web does it pretty easily.

The web? That's the opposite of what was requested here. Most websites look good on desktop but require tweaks to be seen properly on mobile. Not the other way around.

> Most websites look good on desktop but require tweaks to be seen properly on mobile.

This is a weird take. Most web browsing these days is done on a mobile device. Even HN, with its table-based layout, works completely fine on a phone, because it has to- at some point someone put in the minimum to make it work nicely on a mobile screen (basically one meta attribute and perhaps a few CSS media queries). You can build a single web app (without detecting the user's device and switching versions) that scales from the smallest phone to a theater screen thanks to media queries and CSS.

It's even a best practice manifested as "Mobile First Design" that it's better to build a mobile web app first, and get that right, then use responsiveness and media queries to iterate that into a desktop version. I personally think this is a debateable proposition, but it seems weird to state that "most look good on desktop but require tweaks to be seen properly on mobile", when it is in fact the case that most websites and apps are designed for mobile first.

The web is fully capable of delivering an appropriate experience across all form factors, on websites and on web apps. If the web can do it, I don't think it's a pipe dream to capture that capability in a non-web native/cross-plat UI framework designed to do what the web is already doing today. Admittedly CSS is big and crazy and insanely powerful because it has to be, and is probably overkill outside of HTML (though I've seen some UI frameworks approximate it), but a middle ground is definitely possible if you think creatively about it.

Now "possible" and "it exists" are two different things- that's why the web is such an alluring platform: It is probably the single most powerful and flexible user interface framework (in a sense) ever designed.

> when it is in fact the case that most websites and apps are designed for mobile first.

Not my experience at all. If companies care about mobile, they simply make a mobile app.

It is MAUI.

So Avalonia is built on top of Skia which is Google’s portable 2D rendering engine.

So in theory it is as cross platform capable as Chrome/Electron without all the overhead that html brings. Brilliant play, imho.

Now, as long as Apple doesn’t manufacture a reason to ban apps based upon it…

Skia is also used by Android, Flutter and Xamarin, among others.

>> allows you to basically take an old WPF application

Old as in "any old WPF application"?

It seems so, I have been looking into AvaloniaUI for a product and read several articles about people having success porting fairly complex WPF apps that use third-party components like grids.

I'm not sure if "any" applies, I'm sure there are some weird proprietary WPF components out there that'll break somehow. However, XPF does seem to integrate well with popular WPF widget libraries, so support seems very good.

>> Avalonia's big money-maker is their drop-in replacement platform for WPF, which allows you to basically take an old WPF application and turn it into a Windows/macOS/Linux/web application with two lines of code, if you're willing to pay the price

Forgive my ignorance. But what "price" you are talking about, money, or dev time spent to root out the kinks?

I have a WPF application running on Windows, and I am thinking about porting it to Avalonia for the purpose of cross platform. Just for the background

It is a few thousand USD/EUR. It is pricey but inline with most commercial WPF components.

Money, specifically $20k per app per platform (assuming you're not a small startup). That's Avalonia XPF, though, not the open source component; XPF is an alternative platform to target that'll turn WPF into Avalonia without rewriting any code.

If you're willing to rewrite/port code, you can use the open source stuff and get the benefits for free, of course!

the move from framework to core should be smooth outside of a few areas.

- webforms/asp.net framework won't move over easily - windows GUI apps won't move over easily - some windows specific API's didn't come over (such as WPF).

If your app falls into any (or multiple) of the above then you definitely would have experienced pain, but in general the move is pretty smooth.

Yes, I so wish I had gone with Avalonia 3 years ago. I now have a Xamarin.Forms app that is at the end of life, and MAUI media player options are dismal.

> How's Avalonia's mobile support now?

A promising future but not production-ready afaik

Reply on news.ycombinator.com