Pro: Xamarin is Highly Effective for Heavy Offline Apps
The good thing about Xamarin is that it reuses Data Access and Business Logic Layers across platforms, leaving the UI specific to each OS. In practice, the DAL and BLL are certainly worth reusing across platforms when there’s functionality requiring computations locally on the device, like:
- supporting the offline mode
- handling big amounts of data locally
- performing image recognition
- integrating with devices over bluetooth, etc.
I’ve seen my share of apps like this in the enterprise employee-facing environment like warehouses or time tracking activities. Xamarin can reach up to 80% code reuse in these cases - that’s really impressive and makes a good use case for the platform. More importantly, when such amount of code is reused, the whole product gets a different approach. You don’t have two separate sub-teams working on iOS and Android apps; you have one team that is responsible for a single product - that’s clearly an advantage in terms of product development.
Con: Xamarin is Weak for Apps with Heavy UI
In contrast, most consumer-facing apps vary dramatically in structures. Most efforts are focused on making the UI appealing to the customers with all the custom animations and smooth transitions (btw, here’s a good reason why, while DAL and BLL only retrieve data from the server, sometimes cache it locally and send processed information back to the cloud.
Here’s an example of the codebase size in a typical app built with Xamarin without much functionality on the device:
- Common core - 25 kB
- Android - 100 kB
- iOS - 120 kB
Code reuse gets as low as 20%, while overheads and risks (which I will cover later) remain the same. And even if there is more cross-platform functionality, whenever there’s a need for custom UI, Xamarin will end up working excessively.
Unfortunately, Xamarin.Forms do not solve this problem. To quote their official webpage, Xamarin.Forms are efficient for prototyping & data entry apps and weak for custom UI & platform-specific functionality.
In general, we at ELEKS don’t recommend Xamarin for consumer-facing apps.
Pro: Xamarin can Benefit from Both Native and .NET Development
Another great advantage of Xamarin is that it remains native, but allows developers to use C# by wrapping native libraries with the .NET layer, adding little overhead with lots of benefits. This makes Xamarin very customizable and open for all the 3rd party libraries written especially for native iOS or Android environments. So, you can simply wrap any native library yourself and use it in your Xamarin project. Additionally, if you have your back-end written in .NET, you might reuse DTO classes and app logic not only across mobile platforms but also across the front end and the back end.
All this will significantly save development time as well as support efforts. In a typical case of changing the class structure or adding new fields, you may only need to do it once and see the changes in mobile, back-end and web platforms.
But even a jewel like this has limitations. While not all .NET libraries are PCL (Portable Class Library), only this type of projects can be used in Xamarin. For example, one of the basic .NET libs File.IO is not PCL, which means you’ll have to create workarounds with abstractions in code. Luckily, after Microsoft released PCL assemblies with more open licenses, most .NET frameworks became available on Xamarin and many API providers started supporting Xamarin.
Con: Finding Xamarin Professionals is Difficult
With Xamarin, you would either need to teach a .NET developer mobile development or teach a mobile developer .NET. Even though there’s no need to learn Java or Objective-C, they would still need to learn frameworks and platform-specific app architecture with some features induced by Java and Objective-C (e.g. reference counting, excessive use of alien patterns for c#).
It’s challenging enough to find a great iOS, Android or .NET engineer to fit your team and corporate culture. But finding a person that would be a profound specialist in each of these technologies is next to impossible. So, you will have to combine the depth of each skillset with a versatile team, yet each team member would need to have common Xamarin knowledge. Now imagine someone leaving your team and you having to fill this void - that would be challenging.
Still, the situation is a little less critical when we talk about building a mobile strategy. If 10-20 Xamarin projects are being developed simultaneously, you’ll need a big team of Xamarin devs anyway, so team rotation may be less of a problem. The same concept applies to the next point.
Pro: On a Large Scale, Xamarin License Cost is a Good Deal
The cost of Xamarin license is also a curious case. Usually, the price is $999 per dev per platform per year. With a typical team size of 3-4 devs and assuming you have the MSDN subscription discount, you’ll end up with an extra $5k per year. So, if you’re building a single app with a total budget of $40k, that may be an issue. But if you’re building a 5-year plan with a dozen apps, six-figure budget and a core team sharing projects and licenses, you may feel just fine.
Con: Xamarin Still Brings Risks
In the end, all cross-platform solutions bring risks of unplanned or excessive work. As I mentioned before, among other similar platforms (PhoneGap, Appcelerator, Kony, IBM WorkLight, etc.) Xamarin is probably the best compromise between the risk and the reward. But don’t forget the risk is still there.
One of the scariest areas is garbage collection. Take a look at the official docs on the topic. With Android, Xamarin has 2 Virtual Machines running in parallel - Android Runtime VM and Mono Runtime VM. The former is the default VM which works the same way as in the native environment. The latter is a runtime which allows all the .NET features to be used in mobile apps. Both of the VMs have their own garbage collection, and that would have been just fine if only they didn't intersect. The problem is that there are cross-referenced objects between these runtimes, and that results in complex garbage collections mechanics which may cause significant delays in the app.
With iOS, the situation may be even more difficult due to manual reference counting which, if not treated very thoroughly, can lead to memory leaks and app crashes. Obviously, the Xamarin team has now advanced in this direction a lot (with things like New Refcount), but the area is still error-prone for a lot of engineers.
Similarly, you may run into a show stopper when trying to implement something native with Xamarin. Leaving aside numerous UI examples, this may happen with such basic objects as Generics.
Additionally, Xamarin’s framework libraries lead to excessive app file size to be downloaded from Google Play or App Store. The difference varies between 3 MB and 15 MB depending on how much core library functionality is used in the app.
Conclusion: Xamarin in Mobile Strategy - You Never Know
Taking into account all the pros and cons of Xamarin mentioned above, the question for building a single app would be simple: is the reward worth the risk? And in most cases, with clear functionality requirements and business priorities (e.g. UX over cost), it’s easy to find an answer. But if you’re still not sure what your apps will look or behave like, the answer is far from obvious.
Thus, my recommendations are:
- If you’re confident that most of your apps will be employee-facing, that cost-cutting is more important than slick UX and you’re used to .NET as your default technology, then Xamarin is a great option.
- If you know your apps will be mostly consumer-facing, UX is more important than the cost and there are some uncertainties in the development, stick with native development.
- If you don’t know what apps you’ll have to create yet, it’s a matter of risk taking. You either pay less now with a risk to pay twice in the future (choose Xamarin now with a risk to mix native and Xamarin in the future) or pay more now to avoid paying 2x in the future (stick with native).
Xamarin Now: The Things Have Changed Massively Since 2015
Xamarin became a part of Microsoft as one of the .NET flavours — .NET for Mobile. Now it’s free to use as a part of Visual Studio. With the release of Visual Studio for Mac, developers can replicate their Windows code base on Mac and build Mac OS versions of their apps with ease.
Also, Xamarin.Forms moved from version 1.3 to 3.1. Those who worked with 1.3 can definitely appreciate the upgrade; the latest version is much more convenient, reliable and easy to use.
