An updated look at Xamarin has been posted 6/30/15.
Let me say right up front, I have a lot of respect for Xamarin as a company and for Miguel de Icaza as a developer and as a person. I like Microsoft, .NET, and C# and have used .NET since it’s release.
None of that withstanding, I don’t believe Xamarin to be the best choice for mobile development in most cases.
For development platforms the subtleties matter a lot. It’s not just about the problems solved but the problems created. Likewise it’s not just about the benefits for a team but the benefits of others working and integrating with that team. We should consider the size of the ecosystem and support communities and how productivity of designers and QA team members are affected. All of these factors combined with immediate developer productivity determine time to market, quality, and user experience.
Taken separately the reasons below would not necessarily lead me to this conclusion, but in totality they argue against standardizing on the Xamarin toolchain.
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 (http://stackoverflow.com/questions/13058521/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.