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

| | August 5, 2015

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 not only making slower, but Expensive since the licence is about USD $4k for enterprise.

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 or they DO want to spend $4k on it

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.

One Response to “How do I tell my boss working with Xamarin will not make it faster”

  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
    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

    The historical record of these bugs can be reviewed using Xamarin’s
    bug tracker (

    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.


    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.

Leave a Reply