Why So Much Xamarin's?

Currently, if someone has brilliant idea of mobile application, he asks himself: “Why the hell I need to multiply my planned costs for developing, almost per each platform separately – Android, iOS, Windows Phone!?”.

Here’s the answer – most of development processes needs to be repeated against each platform language and API. There is dramatically small portion of things, that could be reused, between platform specific app development, using native approach. Captain Xamarin Forms comes to the rescue, with “common part” of each platform API, as cross-platform API!

Does it mean that developing my mobile application, targeted for multiple platforms and using Xamarin Forms, can cost only money as for one-platform-application? No… yes… not exactly, but overall cost could be noticeably reduced with this framework.

Xamarin Android

Let’s look at the history. In around 2011-2012, Xamarin was mostly known from Mono Android, which was framework for Android apps development using C# language and .NET features, but still with the native approach for views building. It means that the views were implemented using native approach (in XML’s) with all native Android tags, properties and so on.
So if you’ve developed anything for Android in past using Java and XML’s, you should be familiar with layouts and with those Android API tags and properties.

The biggest benefit of using Mono Android (called Xamarin Android currently) is that you are using .NET instead of JDK for developing the whole code (except views).

Android API (prepared by Google in Java language) is available through Mono Android API abstraction – most of classes, methods, properties are mapped one-to-one, and the most differences are related to Java and C# syntax and to naming convention.

Example for using Android native AlertDialog class, which is used for showing UI alert pop-ups, looks like that:

As you can see, the only difference in above example is just naming convention – in Java methods definitions start with lowercase letters, in C# with uppercase.

Of course, sometimes there are some more annoying differences. Annoying, because during developing something with Xamarin Android, you will most probably use Google to find some solutions and you will find Java native solutions for your problems.
However, in my PoV, the Xamarin Android documentation is detailed enough, so you don’t have to search over the whole Internet again and again, and in most cases you can just copy and paste Android Java code, paste it as a C# Xamarin Android code, and only change differences related to naming conventions.

During apps development in Xamarin Android, you need at least: Visual Studio (or Xamarin Studio), Android SDK, Android NDK (if you really need it), Android emulator or Android real device and Java JDK. That’s it! You can just build your own app for Android in C#!

Xamarin iOS

In case of Xamarin iOS, the situation is similar to Xamarin Android – you are developing using C# language (instead of Objective-C or Swift), but you are still using the native approach in case of views – XIB’s or Storyboards.

The Xamarin iOS C# API abstraction is a little bit more complicated, comparing to Xamarin Android. Java syntaxes are similar to C#, but the Objective-C code looks differently, comparing to C#. The good thing is that Swift languange is much more similar to C#, so again, if you are facing some API problem or you don’t know how to code something using native API, you can once again reuse some Swift iOS code, copy and paste, and finally just change a little bit in case of language naming conventions.

During apps development, you need a little bit more than in case of Xamarin Android. If you are developing at Windows, you need at least: Visual Studio, remote connection to OSX device with Xcode and Xamarin Studio, iOS emulator (also via remote connection – it’s included in Xcode) or iOS real device (physically connected to OSX device).

Xamarin Forms – “the king of Xamarin’s”

Let’s go back to the history once again. At 2014, Xamarin released Xamarin Forms.

Someone has just realized, that developing mobile app is just repeating, over and over business logic and UI components, against each platform.
If it’s so, then why not use Xamarin Android and Xamarin iOS potential, and basing on that, why not prepare one framework for everything?

Xamarin Forms has been prepared in a way that each and every platform specific API code, which seems to do the same (from logic/UI perspective), has been packed into a Forms API implementation.

Example:

The most important thing, that we should remember, is that Xamarin Forms API is a “common part” of platform specific API. What’s that means? If something is available for all platforms, it’s probably available in Forms, but if something is just not available at one of platforms, it’s not available in Forms at all!

Example:

And that’s why Xamarin Forms class of this component (Editor) doesn’t provide possibility to use hint feature – as it could be possible to use it only against Android, and not against iOS. That could be inconsistency between those two platforms, what Xamarin Forms does not allow.

The most valuable thing in Xamarin Forms are UI Views.

Yes, Views! You can define Views from XAML code (if you’ve developed something in WPF in past, certainly know the power of XAML) or directly from C# code.

That gives you great abstraction – you just need to tell Xamarin Forms (define inside XAML / C#), that you need Entry in UI, and Xamarin Forms will do magic behind. It will take care of converting those Xamarin Forms UI components to platform specific native UI components, by invoking native implementations of it.
In addition it gives you almost same performance as native, as at the end, real rendered UI view will use native components.

For example – declaring new Entry component inXAML/C# will map it to EditText at Android and to UITextView at iOS, without touching those native components by you as developer.

If you’ve touched iOS XIB views ever, you might know, how piece of **** it is – components in views need to have relations with other components, UI needs to be build using designer skills. Yes, using designer skills, it’s almost impossible to do some changes in source code of View (there are automatically generated components constraints, between UI components, which are just unreadable and untouchable at least for a beginner).

You would be really surprised, how simple building views could be. For example – define Grid, split Columns, Rows, put UI components inside and that’s it! Simple and clear code, easy to maintain and to change if there’s a need.

That’s why Xamarin Forms is known as one code for multiple platforms (called also cross-platform).
Below graph shows difference in using Xamarin Android and Xamarin iOS versus Xamarin Forms, in case of amount of code, shared and used between platforms:

As you can see, using Xamarin Forms (in contrast of using Xamarin Android and Xamarin iOS), you are declaring Views and Views code behind only once, and you are not repeating UI implementation per each platform.

Of course at native native (Android Java, iOS Objective-C/Swift), reusability of code almost does not exist. If you need it, you mostly need to switch to some more “low-level programming language”, like C++ or C.

From my experience, most of that platform specific code in Xamarin Forms is related to custom renders, if we need to tweak/customize a little bit platform native UI components, and it’s needed for project needs.
There might be also needed to write some platform specific code, in case of IO operations on device.

And that’s it? Sounds like a miracle for mobile app development?

Well, the real life is a little bit more complicated.
More abstraction (and native code automapping/invoking native implementation) means some reflections behind, which cause performance issues.
At UI, you might face that sometimes components are being rendered differently – some components inside some other components might i.e. not take all of available space, even using simplest FillAndExpand.
There are a lot of smaller and bigger issues, but for most of them you can fix, by finding solution via Google. Some of them you can also work around by changing some properties (using trial and error method), whether it’s working on each platform in the same way, or not.

Indeed, there are a lot of bugs in Xamarin Forms, they are just annoying and could extend apps development time, as you need to have a look for solutions or workarounds.
However, some time ago Xamarin has been bought by Microsoft, and as they have huge funding, there are lot of bug fixed at latests Xamarin Forms releases and it will be further improved in the future for sure.
Xamarin updates are being released frequently, once per every 2-3 weeks.

Which approach should I use?

Below answer is only my personal opinion, based on personal experience of developing mobile apps.

Use native (or in specific cases Xamarin Android / Xamarin iOS) if:

Use Xamarin Forms if:

Using Xamarin Forms could be better from project budget perspective. Even if it’s impossible to reduce time/cost halfly (developing app for Android and iOS natively vs in Xamarin Forms), because of some platform specific issues/things to do, time and cost reduction should be noticeable.

Another huge benefit of Xamarin Forms, as mentioned before, is that you are implement business logic only once! If there will be any mismatch with customer requirements and implementation, or customer would just need to change something in logic, you have to make changes also just once, and not per each platform separately.

The last word. Where is Windows Phone?

Why haven’t I talked anything about Windows Phone, as it’s also supported by Xamarin Forms?
Mostly because this mobile system seems to be deprecated even by the Microsoft itself. There aren’t any new WP phones, so why to develop anything to dead platform…

Also according to Statista.com statistics from 2016 Q3, Android and iOS, jointly has around 99,3% of global mobile OS market share, while Windows Phone has around 0.4%…