Why Xamarin?

As you know there are two primary platforms for mobile development – Apple’s iOS and Google’s Android. Microsoft still leads in the productivity space and so some companies are developing for the #3 platform as well. The difficulty is that apps for each platform are built using different technologies and skill sets. Building apps for Apple devices requires you to use Objective-C or Swift, Android apps are built using Java and Windows apps using one of the languages that target the .NET platform.

The fact that different tools and programming languages need to be used for each platform means that an app has to be built from scratch for each new platform. For many companies this means building a team for each platform, which is not only expensive but makes it unlikely you’ll be able to share any of the code used to build the apps.  It also means you end up with somewhat different apps on each platform.

There have been several attempts to remedy this in the past. A few years ago Facebook announced that HTML5 was the answer – they would develop all of their apps using HTML5 and effectively wrap those apps in shells for each platform.  This would allow them to use one code base and one team for every platform. Unfortunately these apps were slower than native apps.  They also didn’t look like the native apps, they weren’t able to use the tab controls, switches and sliders from each platform.  Users were not happy and Facebook later abandoned this approach.

Which is where Xamarin comes in. Like the HTML5 approach Xamarin allows you to build just one app for multiple platforms using just one programming language and with just one team. Unlike the HTML5 approach, when Xamarin apps are compiled they produce native apps for each platform, so they’re fast. They also replace generic controls (e.g. a tab control) with a platform specific control, so they look like native apps. As a result, users can not tell the difference between apps built with Xamarin and apps built specifically for a platform.

So far, so good. So what else should you know before making a decision?

First of all, how much shared code you’ll have depends on the design decisions you make. There is always a layer of shared application code for things like local data storage, making web calls and proprietary application logic. At the user interface (UI) level you can also choose to share the majority of the code – which means your apps all look pretty similar – or you can choose to build highly customized UIs for each platform while still leveraging the shared application logic.

You will need platform specific code to access some of the native functionality on devices. For example, if you want to allow users to take a photo of themselves you’ll have to use code that is specific for each platform to access the camera. The same would be true for accessing the GPS and the microphone. In some cases features only exist on one platform – like Live Tiles on Windows – and to take advantage of those you’ll write platform specific code. However, all of this platform specific code is still written in just one programming language and in my experience is a small percentage of the overall investment.

You should also be aware that there are not yet as many developers available who have experience building apps with Xamarin as there are who can build platform specific code. I don’t worry too much about this though, for two reasons. One is that Xamarin uses the C# programming language and there are lots and lots of C# developers in the world, so even if they’ve never used Xamarin the learning curve is minimal. Two, Xamarin is growing very quickly, has a pretty strong and growing community with active forums, third party control developers, user groups and the like.

We have developed platform specific apps and Xamarin apps and have found that Xamarin delivers on it’s promise. It allows us to get to market more quickly on multiple platforms at a lower cost, it reduces the cost of ongoing maintenance and we expect that it will only get better.