Monthly Archives: June 2013

The Case for Xamarin

As an enterprise mobile app developer, you will eventually be faced with the decision of choosing the right tool set to develop cross-platform mobile apps. Should I go native?  Should I go hybrid with Cordova (PhoneGap)? Should I use an HTML5 (Sencha Touch,KendoUI, jQuery Mobile) framework? Each has its own merits and demerits.

There is no question pure native apps offer the best of all metrics. You get the best performing (of course limited by your coding skills) app sporting the best looking native UI and, the best user experience. You can leverage all of the device capabilities. You can use all of the native controls ensuring the app subscribes to the platform paradigms. The app feels and behaves like a native.

HTML5 frameworks have come a long way and offer features often rivaling native controls in their look and feel. You can design great looking apps. HTML5 frameworks are often positioned as the solution for developing cross-platform write-once-run-everywhere apps. But take a step back and mull over this.

Unless you want your app looking the same on iOS, Android, Windows Phone and Blackberry, it’s not a write-once-run-everywhere solution. If you want your apps to subscribe to platform specific UI paradigms, you have to sprinkle branching logic in your UI code. Yes, you may have separated your UI into distinct layers, but to offer platform specific UI, you have to write platform specific HTML5 code.

The case is not any different for hybrid apps either. Once again, unless you are ready to live with your UI satisfying the lowest common denominator, you have to write platform specific UI code.

I am assuming you have abstracted the business logic to back-end services callable from the HTML5 or the hybrid app.

So, regardless of whether you choose to go native or HTML5 or Hybrid you have to write platform specific UI code to ensure your app looks and feels native. You may get away by sprinkling your Javascript with branching code but it will soon turn into a debug hell.

This is where Xamarin can help and shines. Xamarin does not promise that you won’t be repeating your UI work. However, Xamarin affords you the ability to write true native apps leveraging native UI paradigms and controls and yet, share business logic code. To use the cliché, it’s a Win-Win! Xamarin allows you to use XCode (storyboards too) to create your awesome native iOS UI, XAML for your Windows Phone UI and, XML for your Android UI. So just like you would, if you decide to use an HTML5 framework or go the hybrid route, with Xamarin you are coding platform specific UI. However there is no branching. And, the resulting app is a pure native app offering you all the benefits like if you had developed the app in Objective-C, C# or Java. What’s not to like about that, especially if you are coming from a .Net world? If you are going to spend your energy creating platform specific UI, why not channel that to leverage the best native UI each platform has to offer? Many enterprise software systems are created in .Net. You may argue that not all enterprise software is. Most consumer facing apps first target iOS and then Android. C# is an easier transition than Objective-C for someone coming from the Java world.

Think about it.