New Talk: Why you should be using Xamarin

Recently I have started making with a new Xamarin talk.  This one inspired by the many conversations I have had with people who seem so hesitant and skeptical of Xamarin, as well as those who are always asking me what it is is and whether it can truly do what it claims.

So the first thing that is important to understand is why tools like Xamarin exist, which requires us to understand why supporting multiple platforms is a must.  To start, look at how the global mobile marketshare went from this in 2007


To this in 2014 (numbers courtesy of Gartner)


While these numbers can be misleading it clearly shows the tremendous marketshare commanded by Android around the world. The reason I say they are misleading is they represent markets where the establishment of a premium market is either miniscule or not practical (developing countries).  However, in developed nations like the United States the marketshare is much closer.


But, marketshare has never been Apple’s goal with their device.  Its the same reason not everyone drives a Jaguar, the devices are not meant for everyone.  They want the people who are going to spend money and that is one area that Apple users (despite there being less than half by comparison) surpass Android, nearly 4:1 (Gartner).


So, what is clear from this information is that we have to support both platforms.  This is where it gets tricky because when you consider that 99% of apps will be used one time (Nielson) you realize that building a great app is even harder than you probably thought; even more so if you are talking something for general consumption.

So, as developers, we have to ask the question: “How can we build apps that are both usable and cost effective.

If we opt to consider only using the pure native approaches (Objective-C/Swift for iOS and Java for Android) we can certainly develop apps with a great experience that will seem familiar to end users on that platform.  However, that likely means hiring an external resource which could not only be costly monetarily, but also from a knowledge standpoint.  You would not want this mobile developer you helped learn your business so they could write the app to walk out the door and leave your developers to maintain.  Further, we have no ability to share code between Obj-C and Java – so it will either be two code bases or two network intensive applications.

If we go to the other end of the spectrum, and use hybrid web we will be sacrificing many aspects of the experience, including that snappy responsiveness users want in their apps (since we would be relying on the HTML rendering engine to support our apps).  However, HTML/JS/CSS is one of the most common skillsets available today and its likely most organizations have people who could leverage these technologies through tools like PhoneGap or Appcelerator to build apps.  But, too often I have seen organizations take this approach and then regret it later because the app just doesnt perform well in the hands of a user.

This is why my option of choice, is Xamarin.  As a developer who has done Android for three years and Objective-C for two, along with my 7yrs of .NET, I can tell you, the idea of sharing code between all of these outputs, as can be done in Visual Studio, is very appealing.  In fact, at West Monroe, where we use Xamarin for the vast majority of our mobile projects, we can usually attain around 75-80% code sharing using vanilla Xamarin; we have hit 90% when we involve tools like MVVMCross.

There are many who view Xamarin with a degree of skepticism because its hard to believe they can do what they say.  But having used it for the last 2yrs, I can tell you that while I can appreciate the skepticism its simply unfounded.  Xamarin goes to great lengths to ensure that their compiled assembles are not only similar in size and performance to native apps, but actually builds their final assemblies using the same compilers used by native developers.  Yes, you read that right, Xamarin’s final assembly is compiled through Xcode (LVVM).

At the core of this process is the idea of cross compilation through binding.  Xamarin is bound to Objective-C objects such that when the final product is produced, calls to Xamarin methods effectively translate to calling native Objective-C methods.  If you are still questioning the performance of this approach go ahead and download “Skulls of the Shogun”, which is written using MonoGame and uses a shared code base to support a version of the game for Windows Phone, iOS, and Android.  Yes, you can even use Xamarin to build games.

At West Monroe Partners, its a beautiful practice to tell our .NET clients that we can offer them iOS and Android apps in .NET, allowing their experience programmers to assist in the process without learning a new syntax.  Further, since West Monroe is a .NET show primarily ramping up new developers in Xamarin is relatively easy.  In fact, during my last project, we took two newer developers and within 5wks taught them iOS programming through Xamarin, despite them having never touched iOS development previously.  So not only do we get to reuse our existing technical assets and provide our client with a code base that then can help maintain, but we also are able to rapidly expand our team if need requires.

And I want to drive this point home. There is no waiting for new features with Xamarin.  They release their beta’s right in line with everyone else.  At West Monroe, we were beta testing 8.0 features months before it came out.  I would literally receive notice of a new Xamarin iOS beta the same day I received a notice that a new 8.0 beta was available.  And, for your users standpoint, they cannot tell the difference between a Xamarin app and a native Objective-C/Swift app.  In fact, as a Xamarin developer who works in iOS, I use Xcode in many cases to build my iOS interfaces, just as a native developer does.

To review, it is clear, to all, that the mobile landscape is constantly shifting.  Though certainly it has remained largely unchanged over the past couple of years.  But recent history has certainly shown us that nothing is set in stone; ask Symbian.  We need to be able to quickly pivot and create apps for all of the major platforms, but primarily iOS and Android.  And that is one of the things that Xamarin allwos for, create the core of your app share it and build the UI for the platform most desired.  Then turn around and create the UI for the secondary platform, hook into your shared code, and you are done; this is even easier with MVVM.

Our goals as developers are always the same.

  • We want apps that we can feel good about
  • We want apps that we can maintain and extend with reasonable effort
  • We want apps that look good and feel nice
  • We want to share code and not repeat ourselves

Xamarin gives us all of this and allow us to use ONE language for development.  And, while costly, offers a very good alternative to hiring Objective-C/Java developers/consultants that will likely walk out the door once the project is done.

If you are curious to hear the entire presentation, I am hopefully going to be presenting at CodeStock in June, if not other user groups before that.


2 thoughts on “New Talk: Why you should be using Xamarin

  1. During my last two Xamarin projects I managed to achieve approximately 96% portable code by relying heavily on Xamarin.Forms for the UI and XLabs for hardware services such as GPS, camera access, dialer, etc.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s