Should I use Xamarin for Mobile Development? YES you should!

Should I use Xamarin for Mobile Development?  – This a very important question and a question that can cost you alot of time and money if you get it wrong. After wasting many months of my time playing with open web platforms I eventually found Xamarin and since then I’ve not found anything that compares.

So that answer is YES! In my opinion Xamarin is hands down one of the best mobile development platforms available in the market today. Many people don’t know what they’re missing out on by not using Xamarin so I’m going to highlight some reasons I think people should be using Xamarin.

1) It’s Native but with 80%+ code share?

So for those that aren’t aware of Xamarin or how it works, Xamarin allows you to develop apps for iOS, Android and Mac from a single code base. When I say this I don’t mean in a webview or customised API, it actually uses the Native APIs. So for example when developing on Xamarin.iOS you’ll be using UIKit which is the same API that a native developer would be using.

2) C# and F# are Modern languages

C# might not be the hipster language of the year but it is a continually evolving language with solid features like type inference, dynamic types,  language integrated query (LINQ), async/await and first class functions. C# is designed for developing large robust applications. And for the functional types there’s F#.

Both languages have been aggressively developed for many years and it’s not slowing down, C# 6 and F# 4 are soon to be released. If you’ve seen C# a few years ago I encourage you to give it another go as it’s evolved in leaps and bounds.

3) async/await

.. ‘wait but javascript is all async’ i hear you say…  C#/F# async/await is different to what people normally think async is. C#/F# async/await tackles the callback hell problems in rich clients, anyone who works with rich clients will know of these problems. This is a problem that’s attempted to be solved with promises and generators but neither are at the level of async/await.

Here’s a little before/after sample:


doAsync1(function () {

doAsync2(function () {

doAsync3(function () {

doAsync4(function () {


await doAsync1()
await doAsync2()
await doAsync3()
await doAsync4()

4) Watches, Google Glass wearables and the future of devices.

In case you haven’t noticed the future isn’t just mobiles it’s wearables, devices and IOT. Xamarin has same day support for all these platforms including android wear, google glass, Amazon TV and more. As I’ve said before Xamarin uses the Native APIs and compiles down to native so using Xamarin you’re in the perfect position develop all modern platforms.

5) It’s ready now!

All the time I hear people say ‘html is a fast moving target’ or ‘it will get there eventually’. Xamarin is here now, it’s Native and it’s cross platform. Why wait to have a great app when you can have it now and as a bonus know that your application is future proof for future devices.

6) It’s fast and stable

From personal experience the Xamarin traditional (Xamarin.iOS and Xamarin.Android) platform is solid, fast and stable. You’d be hard pressed to find a problem with the core parts of the platform, any app bugs will likely be your own bugs.

7) Documentation

The documentation for Xamarin is solid and there’s 100s of sample app on github. Provided by Xamarin and others in the community.

8) Xamarin.Forms

So how about 100% codeshare and still be Native? Xamarin.Forms allows you to program against a single API and have that single API mapped to native controls on each platform. Hanselman describes it well, ‘Write Once Run Everywhere AND Be Native’.

It’s still early days for the product but the top component developers like Telerik and DevExpress are already developing components for Xamarin.Forms.

9) It’s the best of all worlds (Hybrid and Native)

If you’ve taken a look at my Xamarin mashup blog you’d already know that the possibilities with Xamarin are vast, you can essentially create your own Cordova and you can completely integrate it with your C# Mvvm/c# Native Code. So you have the full power of the .net framework to build your client application architecture which becomes very useful when you have complex requirements like Offline.

10) Large Community

Xamarin uses the .net framework and because of this it’s inherited the pre-existing community, this means that even though it’s a fairly new platform we already have support for Awesome projects like, Fody and ReactiveExtensions/ReactiveUI.

11) Profitable Innovative Company

Xamarin as a company has a passion for enabling mobile developers to deliver leading experiences. Their products cost money Yes.. but it’s good for us as customers. I see many people complain about the pricing but Xamarin charging money for products allows them to put money back into building amazing products for us. This year at Evolve Xamarin released some great new products including Insights – Analytics Cloud Service, a faster Android emulator, Test Cloud and a performance profiler. In the future Xamarin is on the rise and this means our tools are only going to get better and better.

This is why I choose Xamarin and I think you should too….

If you have any questions regarding Xamarin or need any help please contact me I’m always happy to help.



Ultimate guide to ASP.NET MVC and Xamarin.Forms Mashups

In this blog I show you how to take an application and then code share both Razor Views and Business logic with a Xamarin.Forms native application. This integration will allow full sharing between the application, so changes to the Razor views or Business Logic will apply to both projects. The mobile application will also work completely offline in which the Razor Views and Business Logic run completely locally on the device.

And that’s just the start of it! Imagine being able to jump in and out of native/web elements, sharing razor views when it’s a good fit and then jumping into a gorgeous native UI when you like.

This blog takes a already existing ASP.NET MVC project that’s been setup as a sample application with typical Views, Script and Styles.

Video: Seamless Native and Hybrid

Video: 3Way Communication between C#/Native and Hybrid/JS Integration

Diagram: Shared Files Setup

Hybrid Razor File Setup

Diagram: Offline Support with Shared Views and Logic

Offline Mode

Step 1. Create new solutions

Create a new Xamarin.Forms PCL solution and place it in a directory next to the MVC project. Because we’re sharing files between projects the directory setup is important. In this case we can call it JellyBeanTracker.Mobile.

Step 2. Adding the external files and RazorTemplatePreprocessor

In this example I’ve added the files from the MVC project into the XF PCL project as ‘linked’ files. Create a new directory called ‘External’ and add the following files as per the screenshot. ps, to add files right click the directory and hit add files, Xamarin studio will then ask you if you’d like to link or copy files, in this case you need to link.

Screen Shot 2014-08-13 at 8.15.13 am

Secondly you need to add the javascript files and css files to the resources directory on each of the platform projects, as per screenshot.

Screen Shot 2014-08-13 at 8.20.55 am

For each of the razor files you need to right click->properties and set the Custom tool to the RazorTemplatePreprocessor.

Screen Shot 2014-08-13 at 8.22.15 am

Step 3. Clone and Add the MVCPolyfils into your Xamarin.Forms Project

Available here:

Step 4. Use the Polyfils

On the Razor page remove @model and replace with @inherits System.Web.Mvc.WebViewPage<T> (from MVCPolyfils).

This step is required to have the file work in both MVC and the Xamarin.

Screen Shot 2014-08-19 at 9.29.47 pm

Step 5. Install Xamarin.Forms.Labs which has a HybridWebView

I’ve done a few modifications to the Xamarin.Forms.Labs project to get this to work and only just put it in my fork, so you’ll need to get the code from my fork until it gets put in the actual project.

Step 6. Setup the Xamarin.Forms Project, with the Page and PageModels

This step requires knowledge of Xamarin.Forms, if you’ve not used Xamarin.Forms before then there’s some good videos over here:

Step 7. Sharing Business Logic and Offline

It’s possible to have shared business logic between both of the projects. You can share it via file linking, PCL or a shared project. In my sample application I’ve used file linking so it’s the same as the razor files.

In order to share business logic between and Xamarin Native you need to code your business logic classes against abstractions/interfaces. If we take a look at the JellyBeanGraph Calculator we can see that it uses a IDataSource for it’s calculations.

The IDataSource needs to be implemented in two or three places, two places if you’re not supporting offline and three place if you are supporting offline. As you can see in the sample project there’s two sources in the Xamarin project, a LocalDataSource and a RemoteDataSource. These two classes a switched between depending on if it’s online or offline.



Step 8. Diff Logic in Razor Views using compiler directives

It’s not highly recommended to have logic within your Razor views but it is possible to have different view logic between the platforms. If you’re using file linking the best option is it use #ifdefs, to do this you need to add a compiler Symbol to the native project, as per screen shot.

Screen Shot 2014-08-14 at 8.10.36 am

Once you’ve setup the compiler Symbol you can then add setup a static IsNative boolean value in a shared file. As per below.

Screen Shot 2014-08-20 at 9.32.21 am

Finally you can add different functionality for the Native applications within your Razor views.

Screen Shot 2014-08-20 at 9.32.40 am

Step 8. Partial Views and Shared Partials

In the open source project I’ve release with this blog post there’s the ability to use Partial views within the Xamarin app. If you provide the classname as a string into the partial the framework will pick it up and run the razor view locally. In order to have the partials work on both the MVC and Xamarin application you need to have the partial views come from a static variable on a class.

Step 9. Combining the Javascript Logic

It’s also possible to take your javascript files and share them with Xamarin. Mostly they will just function as normal unless you’re doing ajax calls to collect the data. In the case you’re doing ajax calls and want to support offline then you need to communication back and forth between the C#/native and javascript.

There’s three type of communication available in this solution using the HybridWebView (soon to be)in Xamarin.Forms.Labs

a) Injecting javascript from c#

b) Calling a c# method from javascript

c) Calling a c# Func and returning into a closure

Step 9a. Injecting Javascript

Using the HybridWebView available in Xamarin.Forms you’re able to execute javascript from outside a webview. This is as easy as calling a method named InjectJavaScript, as per example below.

 Step 9b. Calling Native Methods

Also using the HybridWebView you’re able to call Native methods, so this is going from within javascript running in the web view out to a native method written in c#. As a little side note, this works with Mvvm so your business logic is contained within your view model.

Registering a method with the HybridWebView.

Calling the native method from javascript

The c# method that’s called from the javascript.

 Step 9c. Calling Native Funcs with Closure support

This one I’m a bit proud of as it’s pretty sweet. Using the HybridWebView you now have the ability to call a Native function and the return values of the Native function is injected back into the original closure. Also same as above this works with Mvvm.

Registering the Function in the WebView

Calling the function from javascript with the closure being called on return.

The c# function that runs

Step 10. Debugging from Safari

Another thing I should mention is Safari has the ability to debug UIWebViews, the setup details can be found here.

Just another (awesome)tool for the belt!

This is just one tool for the belt, it’s not the only mobile architecture that you can implement. There’s also the traditional Xamarin approach(Native UI for each platform) and Xamarin.Forms approaches which are still great architectures for mobile applications.

So when should you use this Hybrid type solution?

My personal belief is that using the HybridWebView is acceptable when the view is Not highly interactive as when interacting with a user you want to have everything looking and feeling native. Really it’s up to you to decided and initially it’s good to prototype and test within a device. Of course when you’ve got a large investment in web/mvc assets this is also a good choice.

All the code is available on, currently it’s only working with iOS devices. I will attempt add other platforms soon.




Xamarin Hack Day Talks, Thanks and Retrospective

In June this year I put together a Xamarin hack day(with some amazing help by SSW)  in Sydney. The idea of the Hack Day was to get Sydney’s most experienced Xamarin professionals and people who want to learn Xamarin together for a day of learning and loving Xamarin. The day started with some presentations on various Xamarin technology’s and then the attendees sat down with their laptops to code with the help of the Xamarin experts.

The vibe of the day was great as everyone was very helpful towards each other and attendees were able to help each other.

People are doing amazing things in Xamarin, we all know this but the problem is that we’re all so busy making great products that we don’t get the time to share notes and that’s why I wanted to start the Xamarin hack day. Thanks to SSW the Xamarin hack day has become even more than I expected, it’s now global. Xamarin hack day events will be hosed worldwide including Brisbane, Melbourne, Hong Kong and more. Visit the Xamarin Hack Day website to find out more details on locations.

I would like to thank the experts and presenters Filip, Alec, Geoffrey, David and Rod. I’d also like to thank Adam Cogan and the SSW team for hosting the event and the huge amount of effort they put into the website. A big thank you to all the attendees who made the day a success.

We’re always taking feedback and improving the days for the attendees, so future hack days are only going to get better. I’ve embedded the videos below for your viewing pleasure.

Please sign up for the next Hack Day at


Introduction to Xamarin

Xamarin.Forms Deep Dive

Introduction to iBeacons with Xamarin

Implementing ModernHttpClient in MvvmCross

Earlier this week Paul Betts started a new open source project called ModernHttpClient which is a Xamarin wrapper around two native libs.

“This library brings the latest platform-specific networking libraries to Xamarin applications via a custom HttpClient handler. Write your app using System.Net.Http, but drop this library in and it will go drastically faster. This is made possible by two native libraries:
On iOS, AFNetworking 1.3.3
On Android, via OkHttp 1.2.1″

While Paul does claim your app will go drastically faster he’s not actually very specific about why it will go drastically faster but after a query I’m now aware that for iOS the AFNetworking library has better thread handling than the standard httpclient. So after some tests I confirmed that for single requests the webclient is no faster than the standard client, I’m yet to test performance in an app with many simultaneous client requests but in theory it should be faster.

If you’re using the Image Downloader in MvvmCross implementing the library is a little tricky, but luckily Stuart has done a great job of keeping it extensible.

To get started you’ll need to clone the repo but because it has external projects you’ll need to use the recursive command.

UPDATE, there’s an easier way to get it: Paul Betts Comment

git clone –recursive

Once you’ve got a copy of it you’ll need to build both the Xamarin binding for AFNetworking and the ModernHttpClient.

The binding solution is in vendor/AFNetworking and the ModernHttpClient is in the root directory.

Now that you’ve built both the assemblies you need to add them to your Xamarin.iOS solution.

After a little dive into the MvvmCross source code I discovered that there’s a simple interface that I can implement and register. If you’re not sure what I’m talking about you can read up on MvvmCross plugins here:

So in the Xamarin.iOS project create a plugins directory and add two files MvxFastHttpFileDownloader and MvxFastFileDownloadRequest.

Because the standard MvvmCross plugins have already registered the interface IMvxhttpFileDownloader you need to make sure you register your downloader last, so put it at the bottom of the InitializeLastChance overide in your setup.cs file.





Getting started with Calabash on Xamarin Studio

Here’s a little setup guide to using Calabash with Xamarin Studio on Mac.

  • In a terminal, go to your Xamarin Studio Solution Directory
    • cd path-to-solution
  • Install calabash-cucumber gem (this make take some time because of dependencies)
    • gem install calabash-cucumber
    • (Note you may need to run sudo gem install calabash-cucumber if you get ERROR: While executing gem … (Gem::FilePermissionError)).
  • Setup your project for Calabash-iOS.
    • calabash-ios setup (Answer the questions and read the output :)
  • Generate a skeleton features folder for your tests
    • calabash-ios gen (this also copies the scripts for “interactive development” into your current dir)
  • Download the Calabash-framework in the project directory(i.e the path where your .csproj
    file is present).

    • cd path-to-mainproject
    • calabash-ios download
    NOTE: you can also download manually from download from their framework downloads link
  • In the Xamarin studio, on the IOS project of your app(say Myapp.ios.csproj), you have to
    configure the option to force load the calabash-framework. The reason that we have to do
    this for calabash-ios is because the calabash server runs as part of the app itself(rather than
    in android the instrumentation server will run on a seperate app). And its better you
    configure this in Debug configuration so that release builds does not have this.
    In the Additional mtouch arguments, configure

    -gcc_flags “-framework CFNetwork -framework CoreGraphics -force_load $(ProjectDir)/calabash.framework/calabash -lstdc++”


  • Now from your solution directory you should be able to run the tests (if the features folder is present)
    The only way I’ve got it working is to prelaunch the app from Xamarin Studio and use the NO_LAUNCH command
    • cucumber NO_LAUNCH=1

Html5 vs Native

For the past two years I’ve been in charge of the development of the mobile version of the Jim2 Business Engine at Happen Business. I wanted to share some experiences we’ve had with going mobile.

Before we move on I think it’s important to understand it’s not just html5 vs native as there’s two types of html5 there’s html5 that’s embedded in a native app and there’s html5 that’s used via a browser. In iOS there’s actually a massive performance difference when using embedded html5.

Believing in the power of html5 and the promise of cross platform we spent the first nine months developing in html5, personally I have a soft spot for JavaScript and html so I was happy. The architecture was done using backbone, jquery and moutashe. We ended up with a working app that ran ok. The primary problem we ran into was even after intense optimisation the html5 app just didn’t run fast enough for the level of user experience we wanted. Second issue was the time spent in optimisation, truth is html5 is build once and optimize everywhere.

We ended up playing around with native applications, and found everything just worked and worked well. There’s quite a hard mental shift in developing native vs html as the way you create UI is very different. From that point on we been having a blast and we’ve come up with an app that’s provides an amazing user experience. It’s very challenging to put a rich business application onto a small touch screen but it can be done with some hard work.

That said there’s definitely some places for html5, if your a end user type website a mobile friendly website is essential. Even though you might go with a native app for user experience you must also consider that many users like to be in their browser, so having a mobile friendly website(in addition to native) is also important for user experience in this case.

Something else you need to consider, ‘is your app an essential part of a users day’? Then a native app is essential. As our users spend over 40 hours a week working we’re an essential part of the users life, so our choice was an app. But also on the roadmap we have a mobile friend website.

TLDR; avoid embedded html5 because of performance issues eg phonegap. If your a website have a mobile friendly version and maybe an app. If your critical function of a users life then a app is a must and a mobile friendly website is good to have.

FYI many companies that once went html5 have now gone back to native include us, Facebook and Xero.

Ps, if you take a look at Senchas response ‘html5 is ready’ to Facebook’s claim ‘html5 is not ready’ please understand its a bit misleading because the comparison is done in a safari browser and if it was embedded performance wouldn’t have been half as good.