This is a post in the series tagged, project: downtozero where I'll be building an app using Xamarin. Follow along to see how it goes.

Any developer considering building an app with Xamarin has a serious decision to make right up front: should you use Xamarin.Forms or Xamarin targeting native UI platforms and What's the difference?

Let's take a look.

Xamarin Native UI (the original)

This is what Xamarin is. It's ultimately a cross platform framework for building apps (mobile and desktop) using C#. That means Xamarin has 100% native API coverage for iOS, Android and macOS. This is great news, but it also means that you have to learn the native API's; a tall order.

In order to truly write cross platform apps, you'll be creating several projects: 1) a shared library or PCL where, hopefully, the majority of your code will live and be shared. 2) An iOS project where you'll have the pleasure of finding out how fun storyboards and autolayout are (spoiler alert: they are horrible, horrible things). 3) An Android project where you'll spend an inordinate amount of time figuring out the difference between a fragment and an activity.

The point is, Xamarin doesn't remove the necessity of learning all of the weird eccentricities of the platforms you're targeting. Xamarin is just providing you with the ability to use a single, shared code-base (in as much as you can) and a single language to work with. It's not a silver bullet. This means that you, as a developer, will be spending a lot of time (weeks at least) reading iOS and Android documentation and then translating code samples to C#.

It's not all bad, it's just a bit more of a commitment then simply learning Xamarin itself. Personally, I've spent countless hours becoming well versed with the iOS API's and spent zero time working with Android. That makes me a single platform developer. When it comes to Android, I'm a noob and I'll have to start over learning the Android API's. Again, it's a long road.

I think this aspect of Xamarin really throws a lot of developers off. There are other frameworks that promise ease of development. Take a framework like Ionic for example. Ionic allows you to write JavaScript and it adapts to each platform's UI standards without the developer having to know much about the underlying API's at all. Ionic is great, it too allows the use of single language targeting all platforms, but ultimately, you're working with WebViews and that's not native (but, don't discount Ionic for not being native because I truly believe Ionic and the Web are the future of apps, but that's a topic for another post).

So, using Xamarin in it's original form is not easy, but you get three distinct advantages: 1) You're using a single language (C#) instead of learning Objective-C, Swift, or Java. That's a huge benefit on it's own. 2) You're truly building a native app. The code you write is executing natively on each platform. 3) In as much as you're able to write shared code, you will write way, way, way less code than you would if you targeted each platform independently. Those three reasons are what makes Xamarin great, but, there's something that makes it even better (in some cases): Xamarin.Forms.


I think that Xamarin.Forms is what most developers think Xamarin promised originally, but it's not. Xamarin.Forms came much later and it was a bit of a side path, an option for simple apps that required very little UI customization. Think of it this way: if you just needed to whip up an enterprise app that did some basic CRUD operations, you could use Xamarin.Forms to create such a simple piece of software and your boss would give you a nice "attaboy" when it's done.

Over time, more was demanded of Xamarin.Forms and it matured. But wait, what is it really? Xamarin.Forms is sort of an extension of the original concept, but it removes the necessity for the developer to learn all of the native API's. With Forms, you can use that wonderful thing we call XAML to write your UI and it will magically work on all major platforms. One PCL, one set of UI code, runs on iOS, Android, UWP using XAML. That's the dream, baby!

Not so fast, turbo. There are serious limitations if you choose Xamarin.Forms. Writing a game? Forget Xamarin.Forms exists. Writing an app that requires a lot of UI/UX goodness using platform specific conventions? You might loose. Point is, Xamarin.Forms does a lot and it will get better and better. But, in order to get a great user experience with your UI, you'll jump through a lot of hoops writing that app with Xamarin.Forms. Along the way, after writing your fifth custom renderer (one for each platform so really ten), you'll ask yourself a question: "would this have been easier if I just chose to use Xamarin natively?" Well, maybe.

So, What Am I Using?

I've been down both paths. My first Xamarin app targeted iOS so I went native API for that. I didn't need to concern myself with Android so it made sense. That app was fairly simple but took me months to write because of the iOS API learning curve. Later, I wrote an app for my employer using Xamarin.Forms. It made good sense. The app was very straight forward in terms of UI. Forms did me well on this app (yep, I got that "attaboy").

Now that I'm ready to re-create DownToZero, I have to decide what to use. I have a few goals with this app: 1) Learn something new. 2) Learn Android. 3) Learn MVVMCross. Okay, that's really one goal (because all three are new to me, but you already got that).

Because of these goals, I decided it makes the most sense to write a Xamarin native app using MVVMCross (which could be used with Forms as well). If I use Forms, I won't learn much Android and I really need to. If I use forms, I'll be limited as far as customizing my UI and that's a large part of the value of this app. Getting deep into the guts of each platform will take more time, but I'll come away having learned a lot more and that's worth the extra time for me.


I've chosen to write this app (DownToZero) using Xamarin as Xamarin was originally conceived along with MVVMCross so I can bind my data and share as much code as possible. It's going to be an adventure and I'm sure I'll wish I chose to use Xamarin.Forms at least twenty times along the way but I'll resist that temptation and stick to the program. More to come...