Home » Android » android – How do I tell my boss working with Xamarin will not make it faster

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

Posted by: admin April 23, 2020 Leave a comment

Questions:

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.

How to&Answers:

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.