Xamarin Forms: it works | Hacker News Reader

Xamarin Forms: it works

sharpnado.com

128 pointsroubachof55 comments

This post actually highlights more of XF's downfalls than positives. I've been a big XF developer for years, and XF has many positives but this example just shows that they needed SkiaSharp, Lottie, and native platform code just to get their app out.

Not to mention the need for additional components such as horizontal scroll, carousel view etc.

If you look at Flutter, most of this app could be done with just the Flutter SDK. Haven't really played much with RN, so not sure how that compares.

That's fair, but I think that XF has a good story around integrations with other frameworks to fill its gaps: SkiaSharp has the SkiaSharp.Views.Forms namespace, for instance, and there's solid documentation on integrating the two, right there on Microsoft's Xamarin.Forms docs. Actually, speaking of docs, Charles Petzold's book on XF is an awesome resource -- I've not seen commensurate investments in documentation made by XF's competitors (admittedly it's not something I track that closely). Similarly XF's ability to add a native control directly to a StackLayout via extension methods makes it fairly straightforward to just drop in a native component if that's what you want to do.

I think it's a reasonable strategy to say "hey, we're not going to be able to solve all the problems, and it's probably not the right way to spend our time even if we could. What we will do is make integration with other solutions straightforward so we're not the bottleneck". Making a strategic choice not to be the bottleneck seems like a good call regardless. That said, the things I've found to be a hassle are things like getting OpenGL working on UWP from C# (tractable, but that's really not how I want to be spending my time).

But yeah, wow what a difference it's made having Microsoft throw their resources at it. My current codebase lets me build for iOS, Mac & UWP at present (I'll get to Android at some point), with really not very much effort. Being able to debug on the Mac version rather than waiting for iOS deploys is just about enough to repay the time investment on its own. I'm anxiously awaiting them getting their web platform support up to snuff -- I'd dearly love to never have to JavaScript again. :)

On the other hand this app would work across desktop OSes as well, whereas Flutter not, as it isn't their focus.

Given past experiences, I am sceptical of using languages not part of platform SDKs for production code.

When I do use such third party languages then the eco-system plays a major role in the decision, and for .NET vs a language clinging for survival, the decision is obvious if I care about having the same code in production in the next couple of years.

I understand the need for some apps to work on desktops, but I haven't personally done any of these before. Just iOS and Android, is all clients ever seem to ask me. So of course Flutter wouldn't work well for desktop atm. But FYI: it is being looked at - https://github.com/google/flutter-desktop-embedding Even seen an MS employee contributing to it as well.

As for Dart, its similar to C# in a lot of ways and certainly is gaining traction. I didn't have any difficulty writing Dart code.

Dart might be similar to C# in syntax, it just has like 1% of libraries available to C#, no IDE support at the same level as C# and no commercial value to put on the CV.

When comparing programming languages one always must look beyond grammar and language semantics.

Flutter is trying to be Dart's Rails, it remains to be seen if it will actually accomplish it.

How are pure Ruby projects doing in the market outside plain Rails apps?

The next step in my view is the addition of quality components to the Forms base, and they are doing just that at the moment. I have reviewed and given input for CollectionView, FontIconSource and other specs that are actively being worked on. I saw Miguel demo-ing my input in .NET Conf in the demo Shell app, so they are listening! You did a few stellar Pull Requests yourself, with the Label Spans.

I took them a long time to restructure the project after Jason Smith's leave of absence, but I think David Ortinau is doing a stellar job and the GitHub project is an exemplary open source project. It needs more community involvement, and the F100 stuff you helped drive was very, very good. Next to better components and adding more resources this is another challenge for the project at hand.

I agree it is a bit of a Linux on the Desktop story, "next year", but taken the task at hand (so many platforms), the pace is not that bad. In the mean time I can produce good apps with a few extra libraries, so what...

Its great they seem to be listening to you, they never really listened to me. F100 was brought about because they weren't listening, and the community had to do things they wanted because Xamarin weren't ever getting around to it.

I put a lot of effort into XF, and at the time, it was the best x-plat development environment (for my usage) around. But Flutter has really highlighted its shortcomings and I don't hold much faith that Shell is going to bring it to the front again.

> downfalls

> SkiaSharp, Lottie, and native platform code

So a healthy ecosystem and easy bridging to native is now a downside? This is like blaming React Native for having a useful ecosystem of components.

A healthy ecosystem and easy bridging to native isn't a downside at all.

But this article is saying look how awesome XF is at all these pretty animations and functions, which are mostly done by other components or custom native code.

And they aren't quick and easy to implement either. But you then compare it to Flutter, and you could do most of it right off the Flutter SDK.

To me it highlights where XF lacks in a cross platform development. Especially when you think of the knowledge you have to know to bring in to use all these components. ActionScript, Skia, and each platforms native API usage.

Or in Delphi/C++Builder using FireMonkey framework, especially after they introduced community editions.

I used xamarin a few years ago for a moderately sized iOS app. It got me about 95% there. That last few percent was brutal, the app kept crashing after coming back from the contact chooser. Couldn't find a way around it, even with latest xamarin version, hot fixes. Was very unfortunate. I'm pretty skeptical of frameworks that abstract away a whole system. Hopefully, xamarin is a lot more stable and powerful these days.

> I'm pretty skeptical of frameworks that abstract away a whole system.

But that’s what every platform does. You only notice it when it doesn’t work.

It has improved a lot in the last year, I started working with it just as Microsoft acquired Xamarin, it was buggy as hell, now it is really solid.

People have been saying that since Xamarin came out though, myself included a few years back.

I often get the feeling that what has happened in "the last year" is that the developer saying it has gotten to know Xamarin well enough to avoid the warts.

This has been my experience with pretty much all of the write once run anywhere cross compiled mobile app frameworks

Xamarin Forms and Mature are two things I've never seen in the same sentence before. Microsoft must have really worked its magic on Xamarin then. The last time I tried XF it was so extremely buggy I got bald from pulling my hairs out. Most errors are extremely vague with no way to debug them and they occur at random times for seemingly no reason.

I used it around 3-4 years back ago for a banking client. I had worst experience (worse than android 2.2 ant + eclipse). However, they put a lot of effort into it. And it could be a lot better now. Microsoft has some great tech, you can't deny it. But how many other solutions need there to be.

Xamarin is very tempting but all projects I have seen that tried to use it went native after a while because of insurmountable problem. I am not sure if I'd bet my project on it.

Just today I was really contemplating how miserable life with Xamarin is.

In the morning, visual studio crashed first thing with a ‘non-fatal’ error.

Then I was making a bug fix in a Xamarin.Forms app - changing a string in the UI. I deploy the app, but the change isn’t there. So I clean and rebuild. Then I redeploy. Change isn’t there. I uninstall the app from the simulator. I delete the output directory. I redeploy - still the change isn’t there. Xamarin was deploying cached packages and I had no idea. Imagine verifying a bug fix or change, which causes a crash, and not knowing because the updated package never gets deployed.

Every once in a while I accidentally double-click a xaml file - big mistake. I get to watch visual studio turn white and not respond for about 35 seconds - time to check email and try not to break something.

In the afternoon, I wanted to connect to my mac while doing work in the background - connecting to the Mac takes ages. Unfortunately that’s not an option - connecting to a server is a modal operation. I have no idea why and it frustrates the heck out of me. Even worse, they have flow problems. If you fail to connect to a Mac, you have to close and re-open the dialog before you can add a new one. You have to do this every single time Visual Studio crashes. Visual Studio crashes at least 5 times a day with even moderate use. Xamarin is a big culprit for the instability, but Visual Studio has its share of fuckups, including mainstream releases that will just stop you from running unit tests until they ship a patch. Or just break your build altogether.

Xamarin Forms is uniquely frustrating because it, for the last ~12 months of my active use, always had a bug in the latest version that affects my product. Every time I upgrade, one bug gets fixed, but another one is added. Their QA is nonexistent and it really shows. And it’s not little things- think controls just don’t render on some platforms, or toolbars are busted on iOS. The newest version has some long-awaited features, but I’m afraid to upgrade. Visual Studio is also really bad nowadays - I really, really, really avoid upgrading; it is usually painful and more than once I’ve had to totally uninstall and reinstall.

The build system is a nightmare. There’s a lot of complexity in Forms and a lot of room for things to go wrong. People come to me with build errors all the time, and the first thing I say is, did you hit the green button again? Because failing once doesn’t mean there’s a problem with your app. There’s all sorts of nonsense that happens with caching, msbuild instances interfere with each other - I’ve had to painfully run builds in serial because yes, running msbuild on two projects simultaneously will break both.

I’ve got a lot more complaints but I’m tired and want to keep it brief.

Xamarin.Forms is (and I recognize that much of the pain I described is really problems with other supporting tools) painful enough that I wonder if it’s worth the benefit of writing C#, and this is coming from a militant C# fanboy.

I was really hoping the Microsoft acquisition would lead to more robust QA efforts, but clearly not.

You may want to try using JetBrains' Rider as your IDE. I've hit similar issues with XF in VS, but Rider has been a much better experience for me. For instance: it won't lose its shit if you double-click a XAML file :)

Also has the benefit of being substantially the same on Windows and Mac, so you can use a Mac directly for Mac / iOS development and everything works pretty much the way it did on Windows. VS on Mac is unfortunately pretty dissimilar to VS on Windows.

This. I don't have experience with Forms, but Rider is a massive improvement over VS on both platforms for "native" Xamarin development. I actually quite liked VS for Windows when I started working with it a couple of years ago, but as of late it seems to have gotten only slower and buggier. Since we do only Android / iOS at my job I don't even bother with Windows anymore. I still "need" VS for Mac to (a) build iOS layouts in interface designer (which is hell, I regularly consider going code only for those) and (b) to deploy Android apps when debugging. Rider will do that, but it doesn't do the fast assembly deployment that VS does so it's very slow even if there are no changes. And thus I write code in Rider, and run through VS. VS for Mac doesn't include as much bloat as VS for Windows, which makes it "better" because it's relatively light and doesn't lock up too long when switching to it. As an editor it's just annoying though. Debugging in it is a necessary pain right now.

If this sounds cumbersome... it is. I find it workable right now but I'm regularly annoyed. Build + deploys fail when I fire them off too soon after changing an .axml file. Builds fail as a rule, not an exception, when there are Xamarin or Android SDK updates. iOS is actually mostly fine, except for the hell that is the designer. All in all none of these things are show stoppers, but I don't think I could wholeheartedly recommend Xamarin for new apps.

That's in line with what I have heard. Xamarin is a source of never ending obscure problems. All projects I know have switched to native from Xamarin by now b

To be fair the native iOS development with Xcode (10) isn't much better. My builds unpredictably fail for no reason at least once a day. Sometimes I have to build three times before all errors disappear, without touching any code or project files at all, mind you.

But at least Xcode doesn't crash any more.

Not Xamarin but Xamarin.Forms. Xamarin just works because it's basically C# bindings to native.

True. I should have been more specific about Forms. But in my company the mobile guys have even given up on Xamarin because it caused more headaches than solved things. First they tried Forms which didn't go well, then native UI with Xamarin backed, didn't go well either, and now they are fully native.

I have many of the issues you have when working VS under Windows; VS under Mac (for iOS dev) a lot less. So because of path of least resistance, I first finish iOS apps on Mac and then compile / test on Android (which is far more of a pain, which I find for React Native as well tbh and for their native ObjC/iOS vs Java/Android as well; my opinion, not saying one is better than the others; probably just what I'm used to). I use Forms as a framework, not 'out of the box'; I have many of my own controls and tooling; I have a live XAML editing environment and a crippled but functional C# scripting implementation to not have to deal with IDE's so much. When Miguel Icaza did a blogpost about the interpreter environment[0] finally getting some love end last year, I was hopeful, but unfortunately it seems development is going so slow that I implemented my own which is buggy for others (let's say unworkable) but allows me to live program on iOS.

I think it will make quite a difference; I know it does for me as I use it for everything, but within the confines of what I could implement in my free time.

Wish Krueger [1] would open source his interpreter as his has many bugs but far far less than mine and it could be a good effort fixing bugs and getting a better project on the iPad at the same time.

A propos ; Continuous is great for playing around with Forms and Xamarin iOS in a fast and responsive environment on an iPad Pro with keyboard. For just getting the screens perfect fast it is pretty good. Not sure why he doesn't have XAML support (or he has but I could not find it so I assumed not) as that is pretty trivial to implement.

[0] https://www.mono-project.com/news/2017/11/13/mono-interprete...

[1] http://continuous.codes

I wonder if blazor+pwa isn't going to be what makes xamarin unecessary. It's still a few years ahead though.

Not really my cup of tea, but always interesting to hear what cross-platform solutions are being used outside of React Native and Flutter. Xamarin is probably number two after RN, and gets a fraction of the buzz.

Buzz depends on which circles one moves on, on the enterprise shops I work with, RN is not even relevant.

If JavaScript is involved it is either a mobile web site or Ionic.

Otherwise Xamarin is the usual option when not going native or betting on JS.

It's interesting- in the Silicon Valley, hip consumer-centric startup scene, native is king. React Native is touted in a pinch; Flutter is the new flavor of favored cross-platform solution that is getting the hype that RN had. Yet I wonder how many firms in the larger world aren't just writing Xamarin apps, but apps using derided old hybrid solutions like Cordova/PhoneGap or Appcelerator.

The world moves too quickly for the non-startup folks to have any hope of staying on the bleeding edge. Even if one does resolve to use the new hotness, by the time the project is completed, the world has moved on. Not even beginning to get into the realities of having to actually support the product for years, on a fractional budget, where major updates and the probable event of breaking changes in updated dependencies introduce unacceptable risk. You really want a set of steady, stable building blocks under those constraints.

I’d say a lot of that is due to history — and the commercial history, bug history, etc. even though it seems XF is definitely top-tier at this point.

Not sure if the OP will see this but http://sharpnado.com/ points to a “parked” page so you probably want a redirect.

I wasn’t able to reproduce this, I wonder if the author fixed it already?

Still showing as parked for me.

Showing parked here still, with Gandi.

Also showing a parked domain...

This app looks beautiful. I agree, Forms is very solid these days. The docs really underplay the capabilities. The library that they built in this article looks awesome! I'm pretty surprised that horizontal scrolling is not natively bundled. A lot of things are still in "alpha" for years, good to call out. I want to see more new components shipped with Forms. Webview is another oldie that hasn't gotten any updates.

I was surprised to learn about SkiaSharp. Isn't Skia what Flutter is built on? I couldn't help imagine how great Flutter would be written in C# rather than Dart.

I actually half built a solution where the Flutter engine was running on Xamarin (hence coded in C#), and got a basic hello world app running. It does have the downfall of slower boot times and larger file sizes though.

But I abandoned it because its too big of a project for a one person side project.

Didn't you experience any (big) performance issue with XF on Android compared to iOS?

Just enable AOT by hacking the proj file and suddenly you have amazing performance in release mode (but bigger APK). Normal builds have been getting steadily better for Android.

Well Microsoft is not using Xamarin for any of their cross platform apps. Why should we?

Microsoft News is made with it: https://twitter.com/migueldeicaza/status/1009433494840336384

That's actually a weird thing with a lot of MS tech, especially .NET desktop development. They barely used Winforms themselves, WPF got only used in Visual Studio 2010 (and made it slow and buggy for the first releases). They put out stuff for developers but don't use it themselves.

WPF has also been used for PowerShell ISE, Windows Live Writer, ABC a bunch of other things. A problem with adopting Windows forms or WPF internally is probably that no Windows core component or application could depend on .NET or non-system libraries, and a lot of applications are older than .NET and certainly wouldn't be rewritten.

Yes, same goes for MFC.

Very true. Does anyone know how the situation is with Apple? Do they use the libraries they have developers work with?

Okay hold on, Xamarin forms doesn't just work. That is a bold faced lie. Xamarin, like many other languages and frameworks has its share of zealots. Coming from a basically agnostic position on mobile development technologies I have found Xamarin to be pretty difficult to work with.

Doing UI work in Xamarin is incredibly verbose while at the same time being underpowered. It certainly does not just work. To give you a better idea of the real state of Xamarin we are JUST NOW getting the ability to underline text https://xamarinhelp.com/hyperlink-in-xamarin-forms-label/.

But Xamarin is chock full of other gotchas. A few off the top of my head:

- there is no real file picker (even third party) let alone a great file picker that can pick files locally and remotely (like from google drive).

- there are a surprisingly limited number of controls available and native or not they often look terrible.

- build times average one to two minutes and the debugger doesn't work about 50% of the time.

- a lot of APIs that you think are supported are not. for example, they say System.Drawing is supported but it's not. So what you end up doing is writing custom implementations for each platform.

I could go on but suffice it to say developing in Xamarin is not something that just works. It ONLY works because developers spend a great deal of time making sure that it works.

As an aside, for my next Xamarin project I am considering doing the UI in a WebView while using C# as the back end. It would be more like a web application than a Xamarin application which would hopefully mean a nicer UI while still being able to leverage C#.

> I am considering doing the UI in a WebView while using C# as the back end

Why not Xamarin + MvvmCross + native UIs? I just finished an iOS + Android app like that and while learning Android UIs on the go was a bit painful (build times are longer when you modify resources), I had no issues except for Visual Studio for Mac quirks.

> doing the UI in a WebView while using C# as the back end.

I have to ask, why not just do a mobile web app?

Yeah, good question. I agree, lol.

In my particular case I do need some C#/Backend functionality that I don't want to have to call a server for.

Let me guess... Some kind of legacy business logic library that nobody in their right mind would want to port to JavaScript? I don't blame you.

That sounds like a use case but in reality it wouldn't work anyhow because it probably relies on Windows functionality that hasn't been ported to or doesn't have a one to one mapping with iOS and Android.

No, It's a steganography application so I don't want to do any of it in a browser which I imagine could be an attack vector.

Yours is a good use case.

Doing everything in JS is so common now that I didn't even think about hiding the source code. I haven't considered it as a factor in a long time, but I do remember it being considered somewhat of a disadvantage for Javascript around 2010.

Reply on news.ycombinator.com