Multi-platform mobile development with Xamarin

Juha Ristolainen • Technology Director

The problem when creating mobile apps is that if you want to cover as much of the market as possible you have to write the app at least twice: once for Android having the biggest market share and once for iOS. In some cases you also need to write it for Windows Phone. That means writing the same app three times. Seems like a huge waste and we don't like waste. There is usually no sharing of code between the apps between platforms unless you write the common logic in a way that is supported in all of them which usually means using C or C++.


With games it’s a bit different since OpenGL is supported in most of them and there are many great tools and frameworks like Unity that abstract the platform away and let you focus on developing the game.


We as developers are always looking for ways to work more efficiently and cover as much of the market as we can. There have been attempts to provide cross-platform approaches to writing mobile apps in the past, namely Qt, but they haven't really taken off massively. Futurice has a lot competence in writing apps also with Qt, but most of the commercial need was when Qt only supported Nokia platforms. Since Digia bought Qt from Nokia they have taken the community initiated Android and iOS-ports, productized them and put them front and center. Presently Qt supports writing apps for Android and iOS (and Windows Phone/WinRT) using their C++-based framework. User interfaces are created using a declarative language called QML. QML is one of the easiest ways of creating mobile UIs in a reactive way up to date. The problem with QML is that it provides only a set of basic drawing primitives and you have to construct your app user interface with those. There are UI component libraries in the works that provide much needed building blocks that will have skinning to make them look like Android and iOS. I don't think they are quite ready for production use yet though. Qt is a viable alternative for writing your mobile app if you have existing skills and want to cover iOS and Android and don’t mind your app looking like your app and not a native Android or iOS-app. As an added benefit of Qt though, you may be able to port your application to Jolla's SailfishOS or Ubuntu Touch since they both use Qt in their development but their impact commercially is non-existent.

Here comes Xamarin

Currently the main tool for me for creating multi-platform apps for Android, iOS (and Windows Phone) is the Xamarin platform. Xamarin's approach is that you still write the app using the same idioms and the same classes as you would normally for the given platform, you just write them with C#. They've done a great job in mapping 100% of Android and iOS APIs (they just announced support for iOS 8 and Android L preview) in their wrappers so you can do anything you can do with Objective-C, Swift or Java with C#. Xamarin is usually pretty fast in covering all the additions to native platforms APIs and they already have support for e.g. Android Wear and Google Glass. Using C# enables you to isolate your common code into separate Portable Class Libraries (PCLs) or shared projects and then just reference them from the platform-specific projects. With C# you also get some C# goodies like async/await, LINQ and of course Rx is also offered. Xamarin is also extending support to other .NET languages and they already have an F# compiler.


Performance-wise an app written in Xamarin is pretty much the same as any other native app written for the platform. There may be a small startup delay but after that you don't really have to worry about it. On iOS for instance the app gets compiled first into intermediate MSIL/CIL and then into native ARM-code. You can even use Apple LLVM if you don't want to use Mono-version.


Xamarin posted some case studies from multi-platform apps made by 3rd parties that are available in app stores where they measured the amount of code reuse for platforms. For iOS you needed to write 20-30% of platform specific code, for Android 15-20% and Windows Phone 10-15%. You can do all the stuff like accessing the camera or the address book by yourself with platform specific APIs or you can use readymade components from the Xamarin Component Store (which is basically nuget for Xamarin components) that abstract the access behind a single API. They have components that provide social media integrations, authentication or device hardware access. The component store has a lot of 3rd party components as well in both free and paid versions.

The newer offering from Xamarin also provides a way to create sharable UIs for all platforms and it is called Xamarin.Forms. This approach resembles the way Qt does things. It’s main use is for line-of-business apps and tools and not consumer grade applications. With Forms you basically create your UI also only once using Xamarin.Forms components which then use platform components to render a native UI on the platform the app is running.

There are also 3rd party solutions on top of Xamarin like MvvmCross that try to achieve even bigger amount of code re-use. MvvmCross relies heavily on the Mvvm-pattern (Model-View-Viewmodel) and data binding you know from Windows Phone development. When using MvvmCross you build your application from the bottom up using the framework idioms. You build your app with ViewModels and all the navigation, commands and logic is implemented in common ViewModels. When you want to navigate to a new view, you navigate to a new ViewModel and the framework finds the appropriate platform specific view and opens it and binds the ViewModel data to the view. You write your views then in a platform specific way but using MvvmCross subclasses of them to enable the databinding magic. MvvmCross relies heavily on Inversion of Control (IoC) and automatic dependency injection to make all this happen. The architecture is a pluggable and access to things like the location are provided by plugins that provide platform specific implementations. To find out a bit more you can check out my slides.

Xamarin’s approach is good if you have skilled team members who already know how to write apps for Android and iOS and are willing to learn C#. It is currently my go-to technology when addressing app needs for multiple platforms. The one negative thing about using Xamarin is the price. There are trials and indie versions for $25/platform available but for a company like us it costs either $999 or $1899 per year per developer per platform. So for us to get licenses for an app project for iOS and Android it will be $1998/developer/year. Also even though the Xamarin Studio IDE is good, it's not nearly as good as Visual Studio.

All the images in this post are taken from Miguel de Icaza's BUILD 2014 presentation which you can find on Channel 9. I highly recommend watching that if you want to know more about Xamarin.

Sign up for Futurice news

Futu Connect is our semi-regular roundup of all things Futurice. Be in the know about career-changing events, industry-leading content, non-profit passion projects, and an ever-changing job board.

Enter your email address below.