Xamarin or Cordova, why?

Xamarin or Cordova, why?

It has become a tradition on this blog to compare things, so let’s keep traditions and compare Xamarin and Cordova. I’m not going to compare them technically, because they’re different. However, they both are meant to build mobile apps, so they both deliver the same end result, just different internally. So why bother with one or the other?

When our customers approach us -specially with a new project-, often this subject is brought up by us. The reason is, the decision of either will have a direct impact on development cost.

TL;DR: Using Cordova implies lower cost of developer and is more extensible, that doesn’t mean Xamarin is a bad choice

Native

As we said before, native is the paramount of mobile development. iOS as well as Android apps are programmed in Swift/Objective-C and Java/Kotlin respectively. There’s a reason why I’m mentioning this, please bear with me. When another entity wants to enhance either platform, it’s done by creating something called SDK (Software Development Kit). The SDKs are meant to expand an app offering without involving the re-coding a certain functionality. Case in point, if you want to add analytics to your app, the same way you use Google Analytics in your web site, the procedure is adding the Google Analytics SDK into your app. The developer just includes the files and code and up you go, your app performance is being tracked by Google just like your website (is not as simple as that, but that’s the gist of it). Platforms SDKs are normally developed in the native language of it.

Hybrid platforms

Cordova (a.k.a PhoneGap), Xamarin, Titanium, etc. are hybrid platforms or IDE (Integrated Development Environment). The main advantage of using them is that native languages development is not needed. By using the hybrid IDE the developer uses one language and the IDE translate those to native. This allows web developers (who normally know html, Javascript, PHP, etc.) to develop a mobile app without knowing anything of Swift or Java. These IDEs exist for a reason, and their success is based on the significant amount of developers who don’t know or don’t have time to learn native coding.

The same way there are SDKs for native, there are also plug-ins or extension for hybrid IDE. This is one of the weak point of using hybrid approach. When a new SDK is published, by default is meant for native use. In order for this SDK to be use on any hybrid IDE, a respective plug-ins must be developed by the entity responsible for it. Going back to our example, if an app is being developed in Cordova and there’s the need to use Google Analytics, then the respective plug-in for it must be used. This chain implies delays in adoption of certain SDK or worst, maybe the SDK is not ported at all, leaving the hybrid IDE outside of that enhancement. It happens.

Therefor as with many things, the more popular the hybrid IDE is, the more support (i.e. plug-ins) it has, the fastest is to develop with. Thus, lowering development cost.

On the hybrid realm, Cordova has the following advantages over Xamarin:

  • Developing language is javascript, while Xamarin is develop using C#. Javascript pool of developers is bigger
  • Due to the previous reason, plug-ing offering in Cordova is wider than in Xamarin

Xamarin though, offers a little advantage in app performance, compared to Cordova. However this is only perceptible to the train eye.

And so we arrive to the point on where the customer/Project-owner has to chose which IDE will be use to develop the app. On our case we support many of them, however when it comes to cost and speed of development, Cordova always has an edge, for one reason or another. This advantage impacts the bottom line and that’s the reason why is so popular, which in turn continues feeding the circle of its life, Cordova that is.