The Promise
In 2011 when Xamarin was founded, if someone told me the story of a .NET and C# platform that could create native mobile apps I would have thought it sounded great. Objective-C was a nightmare for C# aficionados and creating Android apps was no picnic either in spite of using Java which is similar to C#. The total learning curve was massive for developers who wanted to try their hand at mobile apps. The story of Xamarin made perfect sense, or so it seemed.
Fast forward to 2015 and a lot has changed. Xamarin developers have grown into a large and active community, which is incredibly important for any platform in it’s own right. We now have the experience to know it’s possible to build non-trivial native apps successfully with it. The company is heavily investing in new products and services to make it easier to embrace Xamarin for the entire product life cycle.
The biggest problem in all of this is that the original premise (and promise) never held up. In a recent discussion with someone from Xamarin they suggested the product could save having to “re-write your app…from scratch” three times (iOS/Android/Windows). This is partially true, and therein lies the rub. I explained to this person that creating apps for iOS, Android, and Windows has multiple, very different challenges. Xamarin solves some of them. Unfortunately, these are the smaller parts of the problem.
The Good Stuff
Let’s start with the tangible benefits of Xamarin. Writing in a single language is pretty luxurious. iOS and Android projects can coexist in the same solution. With muscle memory in full force mistyping is less common. Syntax, language conveniences, and data collections are familiar and intact. One of my favorite things in Xamarin is being able to whip out something like this from memory and have it work perfectly on all platforms:
.NET collections are fast, powerful, and easy to understand.
Using Java to develop Android apps can get annoying. Imagine having spell out get and set for every property accessor.
Smaller, cleaner code in C# compared to Android/Java
more C# elegance, is vs instanceof
Refactoring is another thing that’s better in Xamarin C# compared to Xcode (iOS). Ironically it’s not as good as using Microsoft C#, because Visual Studio, ReSharper, and CodeRush have reduced functionality with Xamarin projects. For example, you can’t use refactoring to clean namespaces. However Swift in version 2.0 still does not support any refactoring via the latest Xcode beta. This is a big weak spot for Apple and honestly a little embarrassing at this stage.
Speaking of Xcode, a benefit of Xamarin, the biggest I think, is that you do not have to learn or code in Objective-C. Objective-C is actually fairly productive once you’re experienced with it, but the language is both dated and weird compared to what most developers are used to given its Smalltalk/NeXTSTEP roots. When I first learned Objective-C, I resented having to use it and the Xcode IDE which was years behind Visual Studio in many respects.
Support
Whether you use Xamarin as a freelance developer or on an enterprise team, good support is important. While the sample size is small I can easily say my support encounters with Xamarin folks were top notch. I talked to smart people who knew how to work through issues. They were also open to discussions on general topics such as when is it a good fit to use Forms. As you might hope they are passionate about their products, believe in them, and want you to be successful.
The Problems
The biggest disadvantages of Xamarin come down to small productivity increases and stability of the overall platform.
If you try to develop a great app for iOS and Android with a nice, native UX, it turns out the biggest problem is the vast difference in UX architecture between platforms. This is a problem Xamarin doesn’t help you with much. Since these differences are 80%+ of the difficulty, the maximum value Xamarin can offer is really constrained by the 20% of the problem they are addressing.
It’s hard to understate the part of the problem Xamarin does not solve. The difference in UX coding, animation, resources, synchronization, views, workflow, etc., is really night and day between iOS and Android, let alone .NET. While Xamarin allows C# everywhere, it's often C# using two different frameworks with different classes and semantics.
Even if you target only one mobile platform, the benefit of knowing .NET cannot help you with something as simple as loading an image. You learned about the .NET Bitmap class, GDI, etc.? That knowledge is really not very useful for mobile apps. So a key issue here is that Xamarin touts “leveraging existing .NET knowledge”, however this comes with the huge asterisk. A significant part of your .NET knowledge won’t apply here.
When Apple released the Swift language in 2014, it meant that no one is forced to use Objective-C anymore. Swift is a nice, modern language that makes sense intuitively. Unlike Objective-C, I learned Swift easily and naturally. I suspect other C# developers would learn it just as easily. Really the hardest part of C# is mastering concepts like closures (then lambdas come easily) rather that syntax details. Once you understand the concepts the syntax is trivial. Swift is hugely important in terms of development platforms. Swift means one of Xamarin’s biggest benefits, the right to not use Objective-C, is now already provided by Apple.
Stability
After using Xamarin for an extended time it becomes clear the level of quality and stability is significantly below that of Apple’s or Google’s development tools (I would rate Microsoft’s tooling above everyone else’s).
In Xamarin there are bugs, inconsistencies, and limitations that you will come across frequently. No doubt competitors have these problems, but the problem with Xamarin is how often they impact your work which in my experience is every ~2.5 days on average. This subjective formula implies after few months of working on a Xamarin project of significant complexity you will have dealt with a few dozen issues specific to the tooling. I stopped counting mine at about a dozen. Of course this is just a heuristic specific to me and my projects. However, on Apple or Microsoft tooled projects my numbers are an order of magnitude lower. On the contrary it is relatively rare that I find a bug in Visual Studio. In Xcode it’s not super common but not unusual. In Xamarin Studio it’s to the point it significantly impacts productivity.
To provide some sample data, I encountered all of these known Xamarin issues without trying. The coup de grâce was the last one, which actually caused data corruption in files and cost quite a bit of time to recover from:
- http://forums.xamarin.com/discussion/33371/searchview-returning-as-viewgroupinvoker
- http://forums.xamarin.com/discussion/30860/migrating-from-classic-to-unified-api-breaks-my-project
- https://forums.xamarin.com/discussion/24676/unable-to-deploy-any-app-to-ios-device-since-upgrading-Xcode-and-xamarin
- https://bugzilla.xamarin.com/show_bug.cgi?id=18863
- http://forums.xamarin.com/discussion/32204/mass-find-and-replace-doesnt-work-well
Other Points to Consider
Brief points that may affect productivity depending on the circumstances:
- There is no TFS support on Mac in Xamarin Studio. Accessing TFS requires downloading other clients like Eclipse, or running Visual Studio in a virtual machine.
- Don’t be misled by the checkbox that Xamarin Studio has UX designers. They are limited in functionality and Xcode and Android Studio are still required. For example, RecyclerView, a primary Android control is not supported. There are important limitations on iOS as well. The iOS designer became available on Windows with Xamarin 3.0 for Visual Studio in May 2014.
- Xamarin Studio works differently from the Xamarin Visual Studio plug-in. If everyone on your team does not use the same environment, then expect to take some time talking things out. For example, the project file serialization is different between the two, which can confuse source control.
- The edit/build/debug cycle is much slower than working with Apple or Google tools alone. This will depend on your personal cadence, but since I like to iterate a lot this made me feel like I was waiting on the computer too much. Doing a build (not build all) with an empty Xamarin iOS project takes ~20 seconds. This is a long time to build an empty project, even on a 2011 MacBook Pro (Core i7, 16GB RAM, SSD hard drive). By comparison the same system builds an Xcode project with a dozen Swift code files in ~2.5 seconds.
- Consider Xamarin Forms a work in progress. It can be useful if you want to crank out business apps that no one expects users to love, but no one will win an Apple Design Award using Xamarin Forms.
The list of limitations is long. First, not having any designer at all is pretty serious for a UI platform. It's not compatible with Microsoft XAML so this means all of the tooling that exists for it can’t be used right off the bat. It also has feature limitations. For example in XAML or HTML, we simply add an attribute to get hardware accelerated shader effects. This is not possible in Forms.
It’s not that you can't develop apps with it, but it's more of a lowest common denominator approach to UX. Essentially it is not well suited to non-trivial, arbitrarily designed UX. In talking to developers at Xamarin they seemed to agree but that was not an official company statement.
- If you are a developer, you probably use Stack Overflow…a lot. When cutting and pasting useful bits of code often there is no Xamarin version and you have to “port” the samples and tutorials found online. The Xamarin community has grown large, but the amount of community content out there is not even close to that supporting the primary vendors.
- It costs money. Comparing productivity of Xcode to Xamarin Studio is one thing, but remember you have to pay for a subscription to get the most out of Xamarin. The prices for the dev tools, not including services, can be found on their site. The price for the entire suite of Xamarin tools and services can run about $4,000 per year, per developer. However as with Microsoft the prices change a lot and can vary between customers.
Conclusion
The biggest arguments I hear for Xamarin are about the benefits it offers. Indeed, Xamarin has many benefits including a cross platform language for native apps and a suite of products and services that fit nicely with their tools. Xamarin can produce top tier apps (although not with Forms) that will go in the app store and look as good as anything out there. This is all true and good.
However, what really matters is the net gain in productivity after all points are considered. I believe the current value of Xamarin to .NET developers is oversold. Much of .NET doesn’t apply to mobile. With Swift there is no longer a need to use Objective-C with Apple’s tools. Java is outdated but trivial for C# developers to understand.
The stability of Xamarin is a real problem. That alone is enough to disqualify it in choosing a new platform. If I recall correctly the last dev tool that actually corrupted my files was Borland Turbo C.
Most importantly, the problems Xamarin solves are not the hardest ones in mobile development. They are solving problems on the wrong side of the 80/20 rule based on what’s difficult in mobile today. I still cannot recommend Xamarin at this time, but as ever remain open to reevaluating as they progress.
Testing Notes
For this review most of my time with Xamarin Studio was with version 5.71 (build 661-17). Hardware used was a 2011 MacBook Pro (Core i7, 16GB RAM, 1TB Samsung 850 SSD hard drive). For the Xamarin plug-in Visual Studio 2013 was used under VMWare Fusion 7.1.1, allocated with 4GB RAM and 2 CPU cores. Benchmarking was not done in a VM and only reflects Xamarin Studio.
Comments
Comments are welcome but those without verifiable email addresses will be deleted to reduce spam and trolling. Thank you.
Changelog
- 7/15 - Update to reflect designer for iOS became available on Windows with Xamarin 3.0 for VS.
- 7/15 - Added more detail on Xamarin Forms.