7 Reasons Xamarin Can Be a Trouble

We have just one question:

“How a .NET code can perform on app intended to be Java or Objective-C – based?”

With respect to Miguel de Icaza, C# and .NET

Let it be just the beginning of a story. We appreciate the efforts of Miguel de Icaza who actually created the cross platform framework Xamarin after successful implementation of wide-known platforms – GNOME, Ximian and Mono. From the first sight the benefits are obvious: less coding efforts for delivering the same app for several platforms. That means less money for the customers. But first things first.

Though software engineers we work with have average experience of developing Microsoft-based solutions of 5.7 years, we don’t believe Xamarin can be a good choice to implement an app in most cases.

Our development teams started using Xamarin after successful use of code-once-deploy-all platforms like Cordova, Appcelerator etc. The main issue that gives a push to try Xamarin is that it’s the most native.

Opposite to HTML5, a C#-based Xamarin looks very promising and tempting.

So are you deciding on whether to hire a Xamarin team or go native? Or perhaps you are not sure on prolonging the Xamarin subscription license? So in this technical-oriented article we’re going to argue on that issue more from tech lead or software architect’s viewpoint. Join!

The Nuts and Bolts

In order to do justice to Mr. de Icaza, we’ll share several advantages a Xamarin framework can bring you and reasons why it’s so much appreciated:

It works. Really. Our teams have successfully developed and deployed to AppStore and Google Play numerous apps of our customers.
Push notifications sending.
Ability to choose a UI layout at your convenience.
OAuth integration.
Remote REST APIs integrations.
Beacons technology and real time signal processing for location apps.
Inbuilt video streaming.
Ability to integrate social networks (Facebook, Twitter).
Xamarin framework has an embedded SQLite database.
XMPP library that gives an opportunity to build a great variety of apps.

So these 10 points reveal that Xamarin apps are very close to native solutions. The general feeling is that it’s a true working platform allowing to implement multiple features to make the apps look very native.

And good news for all .NET geeks: you can really use all of your beloved and old-shoe technologies like C#, linq, Parallel, Generics etc. Say thanks to a Mono framework that made it possible.

Xamarin is on a rise today so its components library grows rapidly. Components range from user interface controls to code libraries, as well as user interface themes. Everything for the convenience.

And a bonus fact is that lately Microsoft claims to provide a strong support for further Xamarin development.

A smooth start isn’t it?

But where there’s smoke, there’s a fire. Remember?

Xamarin is an open-source .NET solution ran on Mono. It includes its own C# compiler, run-time environment and the core .NET libraries as we mentioned before. Xamarin aims to make C#-based apps run on operational systems other than Windows like Unix, Mac OS, Android etc.

But nothing comes without a price.

Xamarin creates problems itself

Xamarin AOT compiler – that is the name of all Xamarin developers’ nightmare.

The trouble is that it won’t compile a tidily written code like Xcode does it for example on iOS. Your C# code won’t look the same as it was written. So the main drawback of Xamarin is that you won’t have a full control over the code that will run on a device in the end!

Limited UI abilities

Xamarin.Android UI library

Sure, you can easily make the same things you do via Objective-C for iOS or Java for Android, but let’s not judge a book by its cover. For the apps aiming to cross the line and stand out that would be a challenge to go further in terms of UI. So once you like to develop a specific, niche, elegant and ritzy app for you or your customer – forget Xamarin. Since for such needs you’ll have to develop UI separately for every platform in turn. The problems appear in the form of missing features, incompatibility etc.

Xamarin app’s layers

Creating a separate UI layer for every platform is so-called price for ability of using a cross platform mechanisms. That is how your app looks like by layers:

Data Layer – place where all data is stored, namely SQLite or XML files;
Data Access Layer – the “wrap” over the DL for maintaining CRUD operations;
Business Layer – it contains the business logic of your app;
Service Access Layer – this layer is responsible for all operations and integrations with remote services (REST, Json, WCF);
Application Layer – it contains the native code;
User Interface Layer – responsible for interactions with the users.

Literally speaking, all layers arranged above UI layer are cross platform. The percentage of transferable code for them can hardly exceed 50-60%. As a relief for all Xamarin developers we can note, that Xamarin engineers are well informed on that issue and do everything possible to increase these figures.

Xamarin.Mobile solution for code transfer is intended to simplify work with GPS, Camera and contacts, but can’t be an option for other features.

We’re done in terms of code transfer. What’s next?

Xamarin limitations

The limits affect all developing, testing and uploading the app to store issues. The main limit for iOS is that it doesn’t support dynamic code generation. It affects not only compiled Xamarin code, but also the source code. But there are some quotes on that issue and a solution to generate a IL code to have it compiled.

Anyway we are not going to dive deep into technical aspects of Xamarin.iOS and Android limitations. And these docs are must see for you once you consider developing a Xamarin-based app.

Limited sharing of code outside of xamarin

The development team won’t have an opportunity to generate reusable modules and components outside Xamarin environment. Here’s an example: if your Xamarin team has written code inside the Xamarin, they won’t be able to share it with your HTML5 team for the app. Moreover it can’t be used for any iOS/Android app as well since, as we mentioned above, all mobile platforms are of different origins using different incompatible programming languages.

Example of the same code for Objective-C and C#

App’s overheads (apps are “heavy” and require a lot of space on device)

However hard you try a Xamarin app is larger and heavier than native one. In comparison to the native apps it stably occupies a few megabytes more than their Java/Objective-C analogues. Just as an example our development team shared the size of a Xamarin-coded app – 3 MB, meanwhile the same app on Objective-C will occupy only 172 KB.

Another issue is that the more APIs you use, the more storage it occupies on users’ devices. What does it mean for users? They’ll face difficulties installing them. Such apps perform slowlier and demand more space on smartphone.

Ecosystem and Community

That may seem to be a minor reason to come in terms of development. But your development team will spend more time searching the web for appropriate solution of their question. Of course it’s not Xamarin’s fault, but it definitely impacts the process. Just imagine how much time might have been saved if Xamarin support was able to provide appropriate service, 3rd party components or other tools just like Apple, Google and HTML5 do?

The cost

And finally here we are. It depends on your team-size since they charge per developer, but development of a simple Xamarin-based business app will cost at least $1000 per developer yearly up to $1899 for business subscription. We can’t call that pretty cheap.

But some development teams have a rescue plan using trial versions of Xamarin. That’s an option, but definitely can’t be a reason for sustainable cooperation.

So after such promising cross-platform opportunities we know understand that was just the tip of an iceberg. Does Xamarin worth it? Yes, but nothing more than another option to consider. From our clients’ experience we highly recommend not to replace native development. At least for now.

Another reason to choose Xamarin is the need to develop a simple content app or a prototype app in order to have it developed fast and then switch to native development. But still such approach won’t save a lot of time and money.