Ask HN: Is Xamarin worth learning?

As it has always been, my son. I've been hearing the wonders of cross-platform for going on three decades. Be it Unix->MS-DOS, Java on anything, or iOS->Android, there is always a compromise. Prior, it was usually that the app that didn't look native on any of the platforms. These days it seems the compromise is at dev time. But there's no free lunch. Maybe some day, but probably not within my career.

And that's fine, I now know that when the topic of cross-platform comes up to ask "what are we giving up? What will our new pain points be?" What I don't do anymore is think that this time will be different.

I can't tell you where that bar is, but especially if you are a solo developer it can be easy to undervalue your time spent porting your app between platforms.

Beyond that too, even though you don't develop on Windows now, using a cross-platform toolkit at least provides you the option. You might be surprised how many users [1] you can pick up by making a Windows version, and if it is as easy as add a couple more platform specific files to a mostly shared codebase you might get extra users for quite cheap.

[1] Windows phones have dropped to a low percentage, but that low percentage is still countable in millions of devices. Plus, the UWP continues to expand in number of tablet devices and desktops that support it, not to mention Xbox Ones and AR/VR devices.

As a practical matter it had to ship with a library of default renderers for common UI elements, but other than the layout system, those all can be replaced by alternative renderers either in part or in whole. But the scenegraph essentially is the data structure that stores your app's business value (think HTML templates + JS). The renderers can too, but those should be reusable across many apps (think CSS/the value prop of Bootstrap). The scenegraph maximizes intra-app UI code sharing and the renderers maximize inter-app UI code sharing.

It's a hard problem space, and there is no magic bullet. Even the Xamarin.Forms team would tell you that. For many use cases, it's great. The bugs are tricky, since UIKit and Android have major thread safety issues and wildly divergent object life cycles (and Android itself is such a moving target, which any experienced Android dev knows, cough Support Libraries cough). Bugs tend to come from the layout engine because that is the heaviest lift. XF eats complexity that you otherwise have to eat on your own. For many small/under resourced teams, that's the difference between "iOS only" and "Android also" support. If you are resourced for two teams, awesome! If not, but have to support both, you face some hard choices. Xamarin.Forms tops a very short list of available options.

All that's to say that some people use Forms to build really native apps because they understand the patterns Forms is built on, and it's limitations. Every framework has a grain. When you cut with it, the results are quick and smooth. When you cut against it, and the results are tough, course, and possibly cracked.