How do I tell my boss working with Xamarin will not make it faster

Question

I am the only mobile developer in my job. Before I was hired, my currently boss was thinking on using Xamarin as their marketing says the words Shared code and native. I consider myself an advanced Android developer since I've build large information systems. Right now I'm working on simple apps I could finish in a week, but Xamarin is giving me headache since its too buggy, and the reusable code is about 10% that could easily be copy/pasted into iOS, and despite the fact that you can share that 10% code, sometimes you still have to use compilation directives #if / #endif.

I mean, there is no really any advantage for me, since I already know both Java and Objective-C languages. I already have vast knowledge of SQLite and data storage with Core Dataon both iOS and Android SDK so that learning Xamarin will make it slower.

I have already tried to talk them into not going for Xamarin since its only a little code you can share, but they don't seem either to understand.

I need some good argument to convince them not to buy it, so I can do my job in a more productive and faster way. Thank you in advance.

Answer 1

Some good points from Lee Whitney's Blog: Why I Don’t Recommend Xamarin for Mobile Development:

App Overhead

Xamarin based apps have a built in overhead that makes them larger on average. This affects download time and storage used on a device. The minimum additional size is usually a few megabytes and can grow proportionately as the code uses more of the APIs. This is due to the way code from .NET assemblies is statically linked (as native code) into apps as the assemblies are referenced. On Android there is also an extra startup delay for apps for OS specific reasons. To Xamarin’s credit this overhead used to be much greater and the company has made great strides in reducing it. However, the impact on app users is still measureable.

Limited Sharing of UI Code Across iOS and Android

User Interface development is not portable between iOS and Android.
This means APIs, event logic, widgets, and designers must be used and coded differently for each platform. There are a few exceptions to this for common, low level operations.

Xamarin would argue that trying to abstract UI APIs across very different platforms can create unnecessary complexity or lead to a poor user experience with an LCD (lowest common denominator) design. They have a point here. Titanium tries to do this partially, and the result has made many developers unhappy with the inconsistent or unpredictable results. HTML5 apps are more successful at pulling off this UI abstraction without forcing an LCD design, but they do not have the native performance of Xamarin.

UI problems can be some of the most time consuming aspects of developing mobile apps. Despite having a good justification, the important takeaway is that for many mobile UI problems, Xamarin will not save developers or designers time.

Limited Sharing of Code Outside of Xamarin

Xamarin does not allow creation of reusable components or modules outside of it’s own environment. For example, code written in Xamarin cannot be used in native or HTML5 apps. This means any code developed by a team using Xamarin cannot be shared or reused with teams using any other tooling for iOS and Android. How much this matters depends on the situation, but the problem with development is we can’t predict all of our situations. So it’s an uncomfortable limitation to have right out of the gate.

Ecosystem and Community

This is something that is not really Xamarin’s fault. What company has a mobile ecosystem that matches Apple, Google, or HTML5? However, it matters. When developers are 10 times more likely to find results when searching the web about an issue, it directly impacts productivity. The ecosystem of available support, services, and 3rd party components, and related tooling is, and will continue to be, significantly smaller than for native or HTML5 based apps.

The Third Learning Curve

Some concepts and techniques require special knowledge specific to the Xamarin environment. This effectively adds a third learning curve for developers beyond programming language and native APIs. For example, developers having to understand iOS reference counting to avoid problems with Xamarin’s garbage collection (Is this a bug in MonoTouch GC?). Another example is data structures and generics working in subtly different ways (http://docs.xamarin.com/guides/ios/advanced_topics/limitations). These are the types of issues that are hard to see before you actually adopt a new platform, so they merit special consideration.

More Moving Parts

Xamarin introduces it’s own set of bugs that affect product quality and developer productivity. The problem is not that Xamarin has a bad product, but that adding any large or complex system to the app toolchain comes with problems and bugs that do not exist in native apps.

The historical record of these bugs can be reviewed using Xamarin’s bug tracker (https://bugzilla.xamarin.com).

Yes, all software has bugs. The point is when you measure the advantage of adding new tools; the disadvantage of new problems must be factored in.

Summary

In the end we have to try and quantify the benefits of a development abstraction like Xamarin over other abstractions, or over native development. Is C# better than Objective-C? Yes, by far in my opinion, but that’s only one factor. When you add everything up it tips the scales away from Xamarin in favor of other approaches to mobile development. As of 2013 (this stuff can change quickly) I tend to choose a native code solution or an HTML5/Cordova solution. I like both for different reasons and will try to explain some of the decision factors in another article.