Is Xamarin a Good Fit for Your Project?

Code reuse across platforms, and the associated promise of reduced costs and streamlined delivery have placed cross-platform development frameworks in the limelight. Xamarin is positioned to offer best-in-class tools for cross-platform development teams, but trade-offs are inevitable. This article touches upon different aspects of Xamarin implementation to help developers make well-informed decisions for or against its use in their cross-platform projects.

What projects benefit most from using Xamarin?

The perfect match is an app with a massive business logic layer, simple user interface and standard UI controls. How come? Xamarin enables developers to write apps entirely in C# and share the code on Android, iOS, Windows, Mac and even more. In a best-case scenario, developing with Xamarin.iOS and Xamarin.Android, the shared code amounts to up to 75 per cent of the overall project codebase. It comes from data access and business logic layers, and resides in shared projects. But with a sophisticated UI design, overloaded views and custom controls, the desired 75 per cent of the non-interface code is more difficult to attain. In cases like this, the UI layer grabs the biggest piece of the pie, and its implementation may take just as long as building two or three separate native apps. On the other hand, as experience shows, when the same Xamarin team builds UI layers for each of the platforms, the team velocity accelerates with every new platform implementation as developers get a handle on it and become familiar with all requirements.

Does your team fit in?

With Xamarin-savvy developers on board, the question is redundant! But is it possible to deliver the anticipated time and cost savings using an existing, non-Xamarin team and skills? Much depends on the team’s experience with native mobile platforms and their SDKs. For a novice Xamarin team, the learning curve would embrace not only mastering Xamarin itself, but also studying documentation of native mobile platforms, including Android SDK, iOS SDK and native controls for every platform. If you use Xamarin.iOS or Xamarin.Android, the team will have to learn iOS Storyboards and Android’s XML vocabulary for defining UI elements, which is also a great deal of effort. Ultimately, having a couple of iOS and Android app development engineers on board to provide expert advice would suffice to minimise significantly the overall learning curve for the whole team.

What’s on the plus side?

Economy of effort, code re-use and ease of adding new mobile or desktop platforms are among the primary advantages the Xamarin platform has to offer. The C# codebase living in shared projects can be utilised with any platform from mobile to desktop – even outside of Xamarin.

Costs.

Only three months ago, license costs could be the main obstacle to using Xamarin; the business license would cost the developer $999 per year. But with Microsoft’s acquisition of Xamarin, it open-sourced most of the tools. Those who have valid Visual Studio 2013 or Visual Studio 2015 licenses can go to the official Xamarin website and download the platform for free. Or you can install Update 2 on Visual Studio 2015 and enjoy Xamarin out-of-the-box. Among the services that you still need to pay for is Xamarin test cloud standalone product, but this is something that most teams can do without. Open-sourcing Xamarin made using it much easier and is likely to increase its popularity among developers.

Hardware costs should be considered, too. When delivering across platforms, you need hardware for Mac OS X to support iOS SDK and hardware for Windows OS to develop for Windows Phone (Android SDK works on both).

Issues to be (or not to be) anxious about.

Occasionally, developers complain that Xamarin is not mature enough to provide sufficient documentation, samples, forum discussions, etc. However, as Xamarin is a product for cross-development heavily exploiting Android and iOS SDKs, it enables developers to refer to Android- and IOS-themed forums where they can find answers to their questions without the need to refer to Xamarin itself. Moreover, methods in Xamarin borrow their names from native SDKs, which facilitates the searching process.

The presumed trouble searching for third-party libraries is another myth past its sell-by-date. Today, the majority of libraries have been modified to support cross-platform usage. These include database libraries like SQLite.Net, IoC frameworks like Autofac, lots of MVVC frameworks, etc.

The developers section on the Xamarin website contains detailed descriptions, APIs and samples of all methods, which is definitely enough to jump right in and start building your first cross-platform application. For further inquiries, go to Stackoverflow, searching both Xamarin and Android/iOS topics.

Xamarin.Forms vs. Xamarin.IOS + Xamarin.Android: what to choose?

Xamarin.Forms is a recent solution introduced by Xamarin in 2014. It is perfect for developers who are comfortable with XAML (let say, for the majority of .NET developers) as it enables defining the app’s user interface in an XML file using the XAML syntax. In a nutshell, Xamarin.Forms is a cross-platform native UI toolkit that allows developers to create user interface layouts shared across iOS, Android and Windows Phone. This can produce up to 100 per cent of shared application code … well, probably only with “Hello World” kind of apps. The set of native controls offered by Xamarin.Forms is very small. But there is a good reason for that: Xamarin.Forms controls are a wrapper on native controls merged from different platforms and mapped to their native equivalents at runtime. Any attempt to change the appearance and behaviour of these controls will require overriding the process and customising controls on each platform.

Select Xamarin.Forms only if you intend to abandon custom UI for the sake of code sharing. Otherwise, go with Xamarin.iOS and Xamarin.Android. That way, you’ll get direct access to platform-specific APIs and the full sets of native controls, while each platform will be presented as a separate solution. As already mentioned, make sure to get familiar with iOS Storyboard and Android’s XML vocabulary before jump-starting development with Xamarin.iOS and Xamarin.Android.

The final word.

The following checklist offers a quick review of whether or not to adopt Xamarin:
- Is your app’s user interface simple or moderately complex, with no heavyweight elements, extensive view logic, sophisticated design or non-standardised controls?
- Do you have native mobile app developers on board?
- Do you have other cross-platform mobile (even non-Xamarin!) projects in your pipeline?

If you answer yes to all these questions, then mastering Xamarin could be a smart investment for your team in the long run. So open up to this new experience – and have fun!

 Maria Kulikovskaya, web developer, Itransition