Thoughts on Xamarin.Forms: Can We Truly Build iOS and Android Apps With XAML + C#?

More often than not, when a client asks for a mobile app he wants that mobile application to run on multiple platforms.  For the back-end, the decision isn’t hard to make at all: a REST-based service layer is the way to go, oAuth2 is how you handle authorization.  The discussion focuses on the front-end: how should we build our client applications – the part of your code that will reside on phones/tablets?

Without going in too much detail, there’s a few ways to approach this.  The first is to build the client apps in their own languages – one codebase for iOS, one for Android, one for Windows Phone.  If you’ve got the resources (money + people + knowledge), this is a pretty good option – but it tends to cost a lot to build, and especially to support afterwards.  As a client, you’ll essentially have to ensure you not only have the means to hire people to code in those different languages, you’ll also have to ensure you can keep these people at hand to support the application once it’s been published.  It’s a good option, but for a lot of companies it means extra costs they want to avoid.

So, from that, hybrid apps were born, and those exist in different flavours.  The idea is to find a way to share code on the client across different platforms, so the costs to build & maintain the apps go down.

One approach here is to use PhoneGap/Cordova.  This allows us to use HTML/JS/CSS to build an application that can then be deployed across platforms.  It results in an application that consists of a WebView that interprets your HTML, wrapped in a “native” shell, using a native bridge to access platform-specific native API’s.

The resulting app isn’t an actual native app: it’s an app that runs your code in an embedded WebView.  But: it’s a viable option.

Another way to build hybrid applications is by using Xamarin.  It allows you to use C# to write your client-side non-UI code, and you use the platform-specific UI language to build the different UI’s and hook ‘m up to your C# code.  Contrary to Phonegap apps, this does result in a natively built application for each specific platform, but it still requires some extra knowledge for developing it: you’ll have to know the platform-specific UI language.

I dabbled into this in the past, but to be honest, I wasn’t that impressed when I first tried Xamarin (last year).  It might have been my setup, but the developer experience was too buggy at that time for me to consider it a viable option.

But times change.  Recently, the Xamarin people released v3, and it included something *really* interesting: Xamarin.Forms.  This is a new to build native apps with a shared C# code base – and by using the included Form elements, you don’t need to worry about your UI anymore: when you use one of those elements, these are automatically translated to their native counterparts on the different platforms, as this screenshot illustrates:

(Just as an FYI: no, I’m not getting paid to write this blog post 😉  These are simply my thoughts after diving into Xamarin.Forms for a few days.  I do accept free beer though, if anyone want to buy me a drink ;-))

Well, that’s interesting, right?  In a way, and for some apps: definitely.  But as we all know: a lot of apps have specific needs for their UI, and in most apps, you’ll quickly run into something that can’t be done with the included elements.  So, we need a way to extend these forms: a way to build our own UI elements when needed.

Xamarin allows two options here: the first is to combine Forms with Android/iOS/WinPhone specific UI-elements.  That brings us back to the fact that you’ll need to know the platform-specific UI language – the amount of work you’ll have to do in each platform-specific language is less than before, but, well, even if it’s just a small part, you’ll still need developers that are fluent in those languages to build & support the app.

The second option?  Use XAML to build your UI.  For all platforms.  And this is the part that *really* grabbed my attention: does this mean that we can now build cross-platform applications using nothing more than XAML + C#? Let’s look into this a bit more.

When we create a new XAML file for Xamarin Forms, the first thing you notice is the fact that the default namespace is different than what we’re used to from WinPhone/WPF/… apps:

From that, we can say that the the XAML processor used to interpret XAML & translate it to (un)managed object is different than the one from, say, WinPhone.  The differences go a bit further, even.  If we look at how we define a label:

we immediately notice those properties don’t look all that familiar.  So, it’s a different XAML dialect altogether – which makes sense.

Note:  no, you can’t just copy over existing XAML code.  Just like you cannot – or should not – just copy over the HTML you use on your website to a Cordova/Phonegap app or to a Windows Store app – in fact, as said, there are quite a few differences in what’s accepted by the XAML processor used by the XAML dialect Xamarin.Forms uses versus what other XAML flavours (dis)allow.   And that’s a good thing.

 This is, by the way, one of my major gripes with how languages & frameworks are marketed by their vendors and/or OSS admins – and I really do mean almost all of them.  “Use the code you know”, they said.  “It will be easy”, they said.  No, it’s not.   We should not copy over code that’s optimized for one specific framework/language flavour on one specific platform to another platform.   We shouldn’t even *want* to be able to do that.

So, no, it’s not the XAML dialect most of us know from one of the other platforms.  But I’ve got to say I’m pretty impressed.  Even though it’s a different dialect, writing cross-platform XAML in the new dialect feels very familiar. Data Binding support is included, and I can even use my favourite MVVM framework: MVVM Light.

So: what you CAN use is your existing knowledge.  And that’s a lot.   I’d even go as far as to say that this will result in better apps than were you to use something like PhoneGap; a Xamarin application results in a natively built app, while a Phonegap application results in a WebView-wrapped-in-an-app-container.

Would I use this for building cross-platform apps at the moment?  Difficult question. This is obviously a v1 product, and a lot is missing – a visual designer would be nice, for example.  Blend support would be even better.  But I like the direction it’s heading, so I’d probably give it a try.

In essence, if you’re a Microsoft developer, you can now build cross-platform mobile applications using your existing XAML & C# knowledge, and it will result in natively-built apps for those platforms.

That’s a pretty huge deal.