Building a Mobile Strategy with Xamarin: Win or Loss?

UPD November 2018: It has been four years since we reviewed the Xamarin platform as a mobile сross-platform tool and analysed the pros and cons Xamarin had at that time. We focused on two different use cases: Xamarin-based apps intended for use inside the enterprise environment (such as warehouse management and time tracking) and commercial mobile products with a rich UI intended for external customers. You can read our findings below and learn how things have changed since that time.

Based on our experience in delivering custom application development services, we can say that Xamarin for sure is a viable alternative. If you are looking for a platform to build a single app, that is. But will Xamarin be the appropriate tool to implement your entire mobile strategy that can expand to 10 or 20 apps?

Native development is also no panacea since it leaves us with the need to duplicate code for two or three platforms. On the other hand, PhoneGap and alike have poor UX and a high risk of unpleasant surprises. Xamarin, though, seems to have the best of both worlds with near-native UX, up to 80% code reuse, great support from Microsoft, and a fast-growing community of 600,000 developers.

But to answer the original question, we’ll have to take a closer look at some of the most noticeable advantages and drawbacks of Xamarin.

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.

We monitored all these changes and immediately tested the new capabilities in our R&D Lab. We consider Xamarin as one of the most stable and highly functional platforms for mobile applications with a rich UI and native performance. Here are a few reasons why:

Xamarin is a part of the Microsoft ecosystem

As a Microsoft tool, Xamarin has integration with Microsoft’s service ecosystem and influences its functionality. When Visual Studio for Mac (VS4Mac) was released, developers’ user experience significantly improved, allowing for the building of Mac apps using convenient IDE on the PC.
Azure DevOps offer out-of-the-box build/deploy pipelines and extensions.
Microsoft acquired HockeyApp and added it to the AppCenter.ms for Continuous Integration and Continuous Delivery (CI/CD) of mobile applications. We use this service for Alpha and Beta testing of all our apps.
The AppCenter provides four hours of free build time per month per application on Azure DevOps.

Ready-to-use Xamarin components available

Each technology has its dedicated community of fans and every time a new functionality is developed, the likelihood of it being used is about 85%. The Xamarin platform is no exception. Nowadays, the platform offers a big set of ready-to-use components and affords a network availability component, file picker, tools for taking photos and QR scanning.

You can find community-developed components collected on GitHub here and provided by Xamarin here. Adding components to your project is as simple as installing a NuGet package.

Xamarin has a well-developed community

The community grows day by day. The Xamarin platform is open source with many pull requests included in releases. There are many learning resources available, including the option of live communication around Xamarin whenever you need a hand or a piece of advice. One of the rockstar community contributors is James Montemagno. James hosts the highly recommended Xamarin Show on channel 9.

Xamarin frameworks improve quickly

Mobile developers are all about frameworks because we work with them every day. As the Xamarin community grows, frameworks also evolve in number and maturity level. From our experience of working with Xamarin, we can we point to two main frameworks:

MvvmCross: best for Xamarin.Traditional application GitHub
Prism.Forms: best for Xamarin.Forms application GitHub

Approaches to Xamarin development: Xamarin.Traditional vs. Xamarin.Forms

So how can you choose an optimal development strategy to meet users’ needs? From a technical perspective, approaches to Xamarin development can vary by code sharing percentage, customisation of UI for platforms and number of code lines for platform-specific implementations. All they differ dramatically and each has its own pros and cons. Let’s have a look:

MvvmCross

Build your application as a traditional platform developer: use axml for layout on Android and storyboard or xibs for views on iOS. Also, share your business logic among platforms using the power of MVVM architectural pattern and IoC Container.

Xamarin.Forms

In this case, you share the business logic as well as the UI. Moreover, you can customise the look for each control per platform.

However, from the customer’s perspective, it’s an excellent time to have your application on both platforms, as not to limit the user. Another point that needs making is that you need to carefully analyse what is more important for your customer: the user interface and user experience (UI/UX) or a minimised time to market? Answering this simple question will help you choose the right development approach.

As soon as you’re clear with your priorities, you can start planning your development strategy. Here are several different hypothetical cases that differ by the level of technology available and by how much the developer needs to ‘struggle’ to deliver an app.

Case 1: ’Vegetables’

The first case is all about essentials. Let’s imagine your customer wants an application for both Android and iOS platforms, but he is limited in time and money. An application consists of simple UI components. In this case, your choice will be Xamarin.Forms. If your customer is alright to go with a simple UI, you can cut costs sharing the same UI code for both platforms.

Case 2: ’Juicy meat’

Now let’s imagine your customer wants an application for Android and iOS, but with a sophisticated UI/UX and a streamlined communication to its back-end server at the same time. Here, we would choose Xamarin.Traditional and in 95% of cases we would go with MvvmCross.

In the real world, things might be not as straightforward. As your business grows, your application must change and evolve to keep up.

Let’s get back to the first case where the app has been built using Xamarin.Forms with a simple UI. Naturally, the app needs to evolve into a richer UI/UX. No need to fear, with Xamarin and XCommunity there are multiple ways to cope with an upgrade. You don’t need to rewrite the entire application to make the experience more compelling and sophisticated.

Case 3: ‘Caesar salad’

As you have already a big part of your UI available, obviously you would want to reuse it, especially things like the Settings page or information screens. Still, you need to stick to a defined plan here and make some preparations.

First, we would need to move to the MvvmCross framework. It’s as simple as installing the MvvmCross NuGet package; just follow the guide. MvvmCross supports Xamarin.Forms, but as we are moving away from Forms, we need to set everything up for using the Xamarin.Traditional approach.

Xamarin.Forms have a great feature called Native.Forms and these allow you to use Forms Pages as Fragments on Android and ViewControllers on iOS. All you need to do is to create appropriate Activities and ViewControllers for each screen and optionally use existing Forms Pages.

As you can see, Xamarin has unique benefits as well as certain constraints and limitations. You need to clearly understand your business requirements but also be sure to keep the end-user needs in mind to build the right development approach.

And finally, if you’re in doubt, the best option is to ask for a professional consultation. Drop us a line, we'll be happy to discuss your development challenges.