HTML 5 has proven to not be the silver bullet everyone hoped for. By their own admission, Facebook’s biggest mistake was betting on HTML 5. While it works well for content, anything more than that needs native performance. Mobile users demand native performance. The first few seconds of any mobile user’s experience is the most important. Users will uninstall or never again open an app if they are dissatisfied in those crucial first moments. So what is the answer if it’s not HTML 5? There’s a case to be made that it’s Xamarin.
What is Xamarin?
It originates from Ximian, a little company that started an open source project called Mono. Mono is an open source framework that implements .NET for non-Windows platforms like iOS, Android, and Linux. After a series of corporate acquisitions and firings (first Novell bought Ximian, then Attachmate bought Novell, and finally Attachmate laid off the former Ximian developers), Mono and the associated technologies are now supported by Xamarin. Their primary product is a cross-platform IDE for mobile development by the same name.
Xamarin applications are written in C# or F#. Those are .NET framework languages, right? How does that work? As mentioned above, Xamarin uses the Mono framework. Mono is like .NET’s younger sibling. Almost all of the .NET framework has been implemented in Mono. There are many open source projects that work in Mono as well. Have an existing .NET library? It works in Mono too, so you can use it on iOS and Android.
Xamarin code compiles to a native application for the platforms you target. This is not just a language converter or some wrapper for a web application. Applications using Xamarin perform just like an application written in the native language of that platform.
Where is the Catch?
There has to be a catch. There always is. Well, Xamarin’s catch is not within the framework itself. It lies in the user interfaces of the targeted devices. The typical Android user will not use an application that looks like an iPhone app, and vice versa. Users have an expected experience, so you have to accommodate for that. Hardware buttons in Android are also different from hardware buttons in iPhone. User interfaces have to be customized to the platform.
That seems like a big catch when first looking at it. However, upon closer inspection, most of a mobile application’s coding is not interfacing with the user but interacting with web services, making calculations, and so on. A big chunk of the maintenance work also lies within the backend of the application. In non-cross-platform applications, one platform’s updates will run behind the other. The fix or update to match the web service will have to be written in its own language. If your web application is also implemented in .NET, code can be shared with the web application too.
Xamarin users are boasting numbers of up to 80% code sharing (see, for example, this talk presented at Xamarin EVOLVE 2013). When you move the application flow into code sharing using libraries like MvvmCross, your code sharing goes even further.
At Infinity, our test drives of Xamarin have left us impressed with the possibilities of the technology. We’re actively seeking projects where we can put our knowledge to a real-world test — maybe yours will be the first?
Tags: technology mobile xamarin dotnet